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Titel: Verfahren ziiin Obersetzen von Prograiranen fiir rekon- 

figurierbare Architekturen 

1 ■ EinleitTing- 

Die vorliegende Erfindung betrifft das Oberbegrif f lich Bean- 
spruchte. Damit befalSt sich die vorliegende Erfindung mit der 
Frage, wie rekonf igurierbare Architekturen optimal verwendet 
warden konnen und insbesondere damit, wie Anweisungen in einer 
gegebenen Hochsprache in rekonf igurierbaren Architekturen op- 
timal zur Ausfuhrung gebracht warden konnen. 

Um in sog. Hochsprachen geschriebene Anweisungen zur Handha- . 
bung von Daten (Programme) in einer jeweiligen, zur Datenhand- 
habung verwendeten Architektur zur Ausfuhrung zu bringen, sind 
sog. Compiler bekannt, die die Anweisungen der Hochsprache in 
an die verwendete Architektur basser angepaiite Anweisungen 
ubersetzen. Compiler, die dabei hochparallele Architekturen 
besonders unterstiitzen, sind demgemafi parallelisierende Compi- 
ler. 

Parallelisierende Compiler nach dem Stand der Technik verwen- 
den fiir gew6hnlich spezielle Konstrukte wie Semaphore und/oder 
andere Verfahren zur Synchronisation. Dabei werden typischer- 
weise technologiespezif ische Verfahren verwendet. Bekannte 
Verfahren sind nicht geeignet, um funktional spezif izierte Ar- 
chitekturen mit dem zugehorigan Zeitverhalten und imperativ 
spezif izierte Algorithem zu kombinieren. Daher liefern die 
verwendeten Methoden nur in Spezialf alien zuf riedenstellende 
Losungen. 

ERSATZBLATT (REGEL 26) 
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Compiler fiir rekonf igurierbare Architekturen, insbesondere fur 
rekonf igurierbaren Prozessoren, verwenden fur gewohnlich Ma- 
kros, die speziell fur die beg^iinnite rekonf igurierbare Hard- 
ware erstellt wurden, wobei fiir die Erstellung der Makros zu- 
meist Hardwarebeschreibungssprachen wie z.B. Verilog, VHDL 
Oder System-C verwendet werden. Diese Makros werden dann von 
einer gew5hnlichen Hochsprache (z.B. C, C++) aus dem Programm- 
fluss heraus aufgerufen (instantiiert ) 

Compiler fur Parallelrechner sind bekannt, die auf einer grob- 
granularen Struktur, zumeist basierend auf kompletten Funktio- 
nen oder Threads Programmteile auf mehrere Prozessoren abbil- 
den. 

Weiterhin sind vektorisierende Compiler bekannt, die eine 
weitgehende lineare Datenverarbeitung, wie z.B. Berechnungen 
grofier Ausdrticke in eine vektorisierte Form umwandeln und da- 
mit die Berechnung auf superskalaren Prozessoren und Vektor- 
prozessoren (z.B. Pentium, Cray) ermoglichen. 

Vorliegend wird ein Verfahren zur automatischen Abbildung von 
funktional oder imperativ formulierten Rechenvorschrif ten auf 
unterschiedliche Zieltechnologien beschrieben, insbesondere 
auf ASICs, rekonf igurierbare Bausteine (FPGAs, DPGAs, VPUs, 
ChessArray, KressArray, Chameleon, etc.; im folgenden unter 
dem Begriff VPU zusammengef aBt) , sequentielle Prozessoren 
(CISC-/RISC-CPUS, DSPs, etc.; im folgenden unter dem Begriff 
CPU zusammengefaflt) und parallele Rechnersysteme (SMP, MMP, 
etc.) . Hingewiesen wird insbesondere in diesem Zusammenhang 
auf die folgenden Schutzrechte und Patentanmeldungen desselben 
Anmelders: P 44 16 881.0-53, DE 197 81 412.3, DE 197 81 483.2, 
DE 196 54 846.2-53, DE 196 54 593.5-53, DE 197 04 044.6-53, 
DE 198 80 129.7, DE 198 61 088,2-53, DE 199 80 312.9, 
PCT/DE 00/01869, DE 100 36 627.9-33, DE 100 28 397.7, 
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DE 101 10 530.4, DE 101 11 014.6, PCT/EP 00/10516, 
EP 01 102 674.7, PACT13, PACT17, PACT18, PACT22, PACT24, 
PACT25, PACT26US, PACT02, PACT04, PACT08, PACTIO, PACT15, 
PACT18(a), PACT 27, PACT19. Di'-ese sind hiermit zu Offenba- 
rungszwecken vollumf anglich eingegliedert . 

VPUs bestehen grundsatzlich aus einer mehrdimensionalen homo- 
genen oder inhomogenen, flachen oder hierarchischen Anordung 
(PA) von Zellen (PAEs) , die beliebige Funktionen, i.b. logi- 
sche und/oder arithmetische Funktionen und/oder Speicherfunk- 
tionen und/oder Netzwerkf unktionen ausfuhren konnen. Den PAEs 
ist typisch eine Ladeeinheit (CT) zugeordnet, die die Funktion 
der PAEs durch Konf iguration und ggf . Rekonf iguration be- 
stimmt . 

Das Verfahren basiert auf einem abstrakten parallelen Maschi- 
nenmodell, das neben dem endlichen Automaten auch imperative 
Probleraspezif ikationen integriert und eine effiziente algo- 
rithmische Ableitung einer Implementierung auf unterschiedli- 
che Technologien ermeglicht . 

Folgende Compilerklassen sind nach dem Stand der Technik be- 
kannt : 

Klassische Compiler, die haufig Stack-Maschinen-Code generie- 
ren und fur sehr einfache Prozessoren geeignet waren, die im 
Wesentlichen als normale Sequenzer ausgestaltet sind. (vgl. 
N.Wirth, Compilerbau, Teubner Verlag) . 

Vektorisierender Compiler bauen weitgehend linearen Code, der 
auf spezielle Vektorrechner oder stark gepipelinte Prozessoren 
abgestimmt ist. Urspriinglich waren diese Compiler fiir Vektor- 
rechner wie CRAY verfugbar. Moderne Prozessoren wie Pentium 
ben5tigen aufgrund der langen Pipelinestruktur ahnliche Ver- 
fahren. Da die einzelnen Rechenschritte vektorisiert (gepipe- 
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lined) ablaufen ist der Code sehr viel effizienter. Allerdings 
bereitet der bedingte Sprung Problems fur die Pipeline. Daher 
ist eine Sprungvorhersage sinnvoll, die ein Sprungziel an- 
nimmt. Ist die Annahme f alsch,/^ muss jedoch die gesamte Verar- 
beitungspipeline geloscht werden. Mit anderen Worten ist jeder 
Sprung fiir diese Compiler problematisch, eine Paralielverar- 
beitung im eigentlichen Sinn ist nicht gegeben. Sprungvorher- 
sagen und ahnliche Mechanismen erfordern einen erheblichen Zu- 
satzaufwand an Hardware. 

Grobgranulare parallels Compiler existieren im eigentlichen 
Sinne kaum, die Parallelitat wird typischerweise durch den 
Programmierer oder das Betriebssystem markiert und verwaltet, 
also beipielsweise bei MMP-Computersysteme wie verscheiden IBM 
Architekturen, ASCI Red, etc. zumeist auf Thread-Ebene durch- 
gefahrt. Ein Thread ist ein weitgehend unabhangiger Programm- 
block Oder gar ein anderes Prograram. Threads sind daher grob- 
granular einfach zu parallelisieren. Die Synchronisation und 
Datenkonsistenz ist vom Programmierer bzw. dem Betriebssystem 
sicherzustellen. Dies ist aufwendig zu programmieren und er- 
fordert einen wesentlichen Anteil der Rechenleistung eines 
Parallelrechner. Zudem ist durch diese grobe Parallelisierung 
nur ein Bruchteil der eigentlich moglichen Parallelitat tat- 
sachtlich nutzbar. 

Feingranulare parallels (z.B. VLIW) Compiler versuchen die 
Parallelitat feingraunlar in VLIW Rechenwerke abzubilden, die 
mehrere Rechenoperationen in einem Takt parallel ausfUhren 
k5nnen aber einen gemeinsamen Registersatz besitzen. Ein we- 
sentliches Problem stellt dieser limitierte Registersatz dar, 
da er die Daten fur samtliche Rechenoperationen bereitstellen 
muss. Zudem erschweren Datenabhangigkeiten und inkonsistente 
Lese/Schreiboperationen (LOAD/STORE) die Parallelisierung. 
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Rekonf igurierbare Prozessoren weisen eine grolie Anzahl an un- 
abhangigen Rechenwerken auf, die typisch in einem Feld ange- 
ordnet sind. Diese sind typisch nicht durch einen gemeinsamen 
Registersatz, sondern durch BiTsse miteinander verbunden. Da- 
durch lassen sich einerseits leicht Vektorrechenwerke aufbau- 
en, andererseits k5nnen auch einfach parallele Operationen 
durchgefuhrt warden. Durch die Busverbindungen werden entgegen 
der herkoitimlichen Registerkonzepte Datenabhangigkeiten aufge- 
lost. 

Die Aufgabe der vorliegenden Erfindung besteht darin, Neues 
fiir die gewerbliche Anwendung bereitzustellen. 

Die Losung dieser Aufgabe wird in unabhangiger Form bean- 
sprucht. Bevorzugte Ausfiihrungsf ormen finden sich in den Un- 
teranspruchen . 

Es wird also vorgeschlagen, fur einen Compiler far rekonfigu- 
rierbare Prozessoren die Konzepte von vektorisierenden Compi- 
lern und parallelisierenden {z.B. VLIW) Compilern zugleich an- 
zuwenden und somit auf feingranularer Ebene zu Vektorisieren 
und parallelisieren. 

Ein wesentlicher Vorteil besteht darin, dass der Compiler 
nicht auf eine fest vorgegebene Hardwarestruktur abbilden 
muss, sondern die Hardwarestruktur mit dem erf indungsgemaBen- 
Verfahren so konfiguriert werden kann, dass sie optimal fur 
die Abbildung des jeweiligen compilierten Algorithmus ■ geeignet 
ist. 

2 . Beschreibung- 

Als Grundlage zur Abarbeitung praktisch jeder Methodik zur 
Spezif izierung von Algorithmen wird der endliche Automat ge- 
nutzt. Die Struktur eines endlichen Automaten ist in Figur 1 
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abgebildet. Ein einfacher endlicher Automat zerfallt in ein 
kombinatorisches Netz und eine Registerstuf e zum Zwischenspei- 
chern von Daten zwischen den einzelnen Datenverarbeitungszy- 
klen . 

Ein endlicher Automat fiihrt eine Anzahl rein kombinatorischer 
(also z.B. logischer und/oder arithmetischer) Datenmanipula- 
tionen aus, um danach einen stabilen Zustand zu erreichen, der 
in einem Register (sat z) reprasentiert wird. Basierend auf die- 
sem stabilen Zustand wird entschieden, welcher nSchste Zustand 
im nachsten Verarbeitungsschritt erreicht werden soil und so- 
mit auch, welche kombinatorischen Datenmanipulationen im nach- 
sten Schritt durchgefuhrt werden sollen. 

Beispielsweise reprasentiert ein Prozessor oder Sequenzer ei- 
nen endlichen Automaten. In einem ersten Verarbeitungsschritt 
kann eine Subtraktion von datendurchgefiihrt werden. Das Ergeb- 
nis wird gespeichert. Im nSchsten Schritt kann basierend auf 
dem Ergebnis der Subtraktion ein Sprung durchgefuhrt werden, 
der je nach Vorzeichen des Ergebnisses in eine andere Weiter- 
verarbeitung fahrt. 

Der endliche Automat ermcsglicht die Abbilduhg komplexer Algo- 
rithmen auf beliebige sequentielle Maschinen, wie in Figur 2 
abgebildet. Der dargestellte komplexe endliche Automat besteht 
aus einem komplexen kombinatorischen Netz, einem Speicher zum 
Ablegen von Daten und einem Adressgenerator zum Adressieren 
der Daten im Speicher. 

Nun kann jedes beliebige sequentielle Programm grundlegend als 
endlicher Automat interpretiert werden, wobei aber zumeist ein 
sehr groBes kombinatorisches Netz entsteht. Bei der Program- 
mierung klassischer "von Neumann" -Architekturen - also bei al- 
ien CPUs - werden daher die kombinatorischen Operationen in 
eine Folge von jeweils einzelnen einfachen, fest vorgegebenen 
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Operationen (OpCodes) auf CPU-interne Register zerlegt. Durch 
diese Zerlegung entstehen Zustande zur Steuerung der in eine 
Folge zerlegten kombinatorischen Operation, die aber innerhalb 
der ursprtinglichen kornbinatoriTschen Operation per se nicht 
vorhanden sind, bzw. nicht benotigt warden. Daher sind jedoch 
die abzuarbeitenden Zustande einer von Neumann Maschinen 
grundsatzlich von den algorithmischen Zustanden eines kombina- 
torischen Netzes, also den Registern endlicher Automaten zu 
unterscheiden. 

Es wurde nun erkannt, dass die VPU-Technologie (wie sie im We- 
sentlichen durch einige oder alle der Schriften PACTOl, 
PACT02, PACT03, PACT04, PACT05, PACT08, PACTIO, PACT13, 
PACT17, PACT18, PACT22, PACT24 definiert ist, die durch Bezug- 
nahme volluinf anglich eingegliedert sind) im Gegensatz zu den 
starren Opcodes von CPUs ermoglicht, komplexe Instruktionen 
entsprechend eines abzubildenden Algorithmus wie in flexiblen 
Konf igurationen hineinzukompilieren. 

2 . 1 Arbextsweise des Compilers 

Besonders vorteilhaft ist bei der Arbeitsweise des Compilers, 
wenn die komplexen Instruktionen derart generiert werden, daB 
diese mOglichst lange in der PAE-Matrix ohne Rekonf iguration 
ausgefuhrt wird. 

Der Compiler generiert weiterhin den endlichen Automaten be- 
vorzugt aus dem imperativen Quelltext derart, daB er der je- 
weiligen PAE-Matrix besonders gut angepasst ist, also solche 
Operationen darin vorgesehen werden, die die typisch grobgra- 
nularen Logikkreise (ALUs etc.)/ gegebenenfalls auch vorhande- 
ne feingranulare Elemente (FPGA-Zellen in der VPU, statemachi- 
nes etc.) besonders effizient nutzen. 
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Der compilererzeugte endliche Automat wird dann in Konfigura- 
tionen zerlegt. 

Das Abarbeiten (InterpretiererjO des endlichen Automaten ge- 
schieht auf einer VPU derart, dafi die generierten Konfigura- 
tionen succesive auf die PAE-Matrix abgebildet werden und die 
Arbeitsdaten und/oder Zustande, die zwischen den Konf iguratio- 
nen zu ubertragen sind, in Speicher abgelegt werden. Dazu kann 
das aus PACT04 bekannte Verfahren bzw. die entsprechende Ar- 
chitektur verwendet werden. Dieser Speicher wird vom Compiler 
bestiinmt beziehungsweise vorgesehen. Es reprSsentiert eine 
Konf iguration dabei eine Mehrzahl von Instruktionen; eine Kon- 
figuration bestiirant zugleich fiir eine Vielzahl von Takten die 
Arbeitsweise der PAE-Matrix, wahrend dieser Takte wird eine 
Vielzahl von Daten in der Matrix verarbeitet; diese stammen 
aus einer VPU externen Quelle und/oder eineiti internen Speicher 
und werden an eine externe Quelle und/oder einen internen 
Speicher geschrieben. Die internen Speicher ersetzen dabei den 
Registersatz einer CPU nach dem Stand der Technik derart, dali 
z.B. ein Register durch einen Speicher reprasentiert wird, wo- 
bei nicht ein Datenwort je Register gespeichert wird, sondern 
ein gesamter Datensatz je Speicher. 

Wesentlich kann auch sein, dafi die Daten und/oder Zustande der 
Verarbeitung einer ablaufenden Konf iguration compilerbestimmt 
in die Speicher abgelegt werden und somit der nachsten ablau- 
fenden Konf iguration zur Verfiigung stehen. 

Ein bedeutender Unterschied zu Compilern, die auf Instruk- 
tionsbasis parallelisieren, besteht somit darin, daii das Ver- 
fahren die PAE-Matrix derart konfiguriert und rekonf iguriert, 
dass eine konf igurierte Folge von kombinatorischen Netzen auf 
einer VPU emuliert wird, wahrend herkommliche Compiler gelade- 
ne Folgen von Instruktionen (OpCodes) kombinieren, wobei eine 
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Instruktion als ein kombinatorisches Netz betrachtet werden 
kann. 



2 . 2 Ausfuhmngsbeispiel WHIIiE-Sprache 

Im Folgenden soli die Funktionsweise des Compilers anhand ei- 
ner einfachen Sprache beispielhaft verdeutlicht werden. Dabei 
wird von einer Sprache ausgegangen, die in ihren Grundlagen 
bereits bekannt ist, wobei in einer bekannten Verof f entlichung 
[Referenz "Doktorarbeit Armin Nuckel"] jedoch lediglich die 
Abbildung einer Funktion auf ein statisches kombinatorisches 
Netz beschrieben wird, wahrend mit der Erfindung nun die Ab- 
bildung auf Konfigurationen erfolgt, die dann in einer zeitli- 
chen Reihenfolge entsprechend des Algorithmus und der sich 
wahrend der Verarbeitung ergebenden Zust^nde auf die PAE- 
Matrix abgebildet werden. 

Die Programmiersprache geht davon aus, dass neben einfachen 
logischen und/oder arithmetischen Verkniipfungen ein Befehl 
"WHILE" existiert, der mit folgender Syntax definiert ist: 
WHILE. . . 



MSgliche Konstrukte sind damit: Anweisung 

Folge von Anweisungen 
Schleife 

Eine Anweisung oder eine Folge von Anweisungen ist durch das 
beschriebene Compiler-Verf ahren auf ein kombinatorisches Netz 
abbildbar . 

Figur 3a zeigt ein kombinatorisches Netz mit den dazugehoren- 
den Variablen. Dabei kann sich der Inhalt ein und derselben 
Variable (z.B. xl) von einer Stufe (0301) des Netzes zur nach- 
sten (0302) Sndern. 
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Diese VerSnderung ist beispielsweise fur die Zuweisung 

xl := xl + 1 

in Figur 3b dargestellt. 



Zur Adressierung zum Lesen der Operanden und zum Speichern der 
Ergebnisse kSnnen nun Adressgeneratoren mit dem kombinatori- 
schen Netz der Zuweisung synchronisiert werden. Mit jeder ver- 
arbeiteten Variable werden entsprechende neue Adressen fur 
Operanden und Ergebnisse generiert (Figur 3c) . Die Art des 
Adressgenerators ist prinzipiell beliebig und hangt von den 
Adressierungsschematas der compilierten Applikation ab. 
FUr Operanden und Ergebnisse konnen gemeinsame, kombinierte 
Oder vollstandig unabhSngige Adressgeneratoren implementiert 
werden. 

Typischerweise werden bei der Datenverarbeitung wie im vorlie- 
genden Datenverarbeitungsmodell eine Mehrzahl von Daten inner- 
halb einer bestimmten Konf iguration der PAEs verarbeitet. Be- 
vorzugt ist der Compiler daher fiir die in vielen, wenn nicht 
den meisten Anwendungen moglichen einfachen FIFO-Modus ausge- 
legt, der ziomindest- fiir die Datenspeicher anwendbar ist, die 
innerhalb dieser Beschreibung ziam Speichern von Daten und Zu- 
standen der Datenverarbeitung (quasi als Ersatz eines gewOhn- 
lichen Registersatzes herkommlicher CPUs) dienen. Mit anderen 
Worten dienen Speicher der temporaren Speicherung von Varia- 
blen zwischen den Konf igurationen. Auch hier ist eine Konf igu- 
ration ahnlich einer Instruktion eines normalen Prozessors und 
die Speicher (insbesondere eine Mehrzahl) sind vergleichbar 
mit dem Registersatz eines normalen Prozessors. 



2.2.3 Folqen von Anweisungen 

Eine Folge der beispielhaften Zuweisung lafit sich wie folgt 
generieren (Figiair 4a) : 
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xl := 0; 
WHILE TRUE DO 

xl := xl + 1; 

Diese Folge laBt sich nunmehr ,ftiittels einer Zuweisung geraafi 
2.2.1 und Adressgeneratoren ftir Operanden und Ergebnisse ab- 
bilden. 

Endliche Folgen 

Der Vollstandigkeit halber soli eine besondere Ausgestaltung 
von Folgen abseits der definierten Konstrukte der WHILE Spra- 
che diskutiert werden. Eine endliche Folge der beispielhaf ten 
Zuweisung laiSt sich wie folgt generieren: 
FOR i:=l TO 10 

xl := xl + 1; 

Eine derartige Folge laiit sich durch zwei Arten implementie- 
ren: 

a) Durch Generierung eines Addierers zur Berechnung von i ent- 
sprechend des WHILE-Konstruktes (siehe 2.2.4) und eines 
weiteren Addierers zur Berechnung von xl . Die Folge wird 
als Schleife abgebildet und iterativ berechnet (Figur 5a) . 

b) Durch Auswalzen der Schleife, wodurch die Berechnung von i 
als Funktion entfailt. Die Berechnung von xl wird i-mal in- 
stantiiert und als Pipeline aufgebaut, wodurch i nacheinan- 
der geschaltete Addierer entstehen (Figxir 5b) . 

2.2.4 Bedingungen 

Bedingungen lassen sich mittels WHILE ausdrUcken. Beispiels- 

weise: 

xl := 0; 

WHILE xl < 10 DO 
xl := xl + 1; 

Die Abbildung generiert eine zusatzliche PAE zur Verarbeitung 
des Vergleiches. Das Vergleichsergebnis wird durch ein Sta- 
tussignal reprasentiert (vgl. Trigger in PACT08) , das von den 
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die Anweisung verarbeitenden PAEs und den Adressgeneratoren 
ausgewertet wird. 

Die resultierende Abbildung ist in Figur 4b dargestellt. 

Durch die Auswertung der Bedingung (hier WHILE, generell und 
einleuchtenderweise auch andere Anweisungen wie IF; CASE rea- 
lisierbar) wird ein Status generiert, der der nachf olgenden 
Datenverarbeitung zur Verfagung gestellt werden kann (DE 197 
04 728.9) und/oder an die CT Oder eine lokale Ladesteuerung 
(DE 196 54 84 6.2) gesendet werden kann, die daraus Information 
iiber den weiteren Programmf luli und evtl. anstehende Rekonfigu- 
rationen ableitet. 

2.2.5 Grundlegendes Verf ahren 

Entsprechend den vorherigen Verf ahren wird jedes Programm in 
ein System abgebildet, das wie folgt aufgebaut ist: 

1. Speicher far Operanden (vgl. Register einer CPU) 

2. Speicher fur Ergebnisse {vgl. Register einer CPU) 

3. Netzwerk aus a) Zuweisungen und/oder b) Vergleichen- 
Anweisungen, also Bedingungen wie z.B. IF, CASE, Schleifen 

(WHILE, FOR, REPEAT) 

4. Optionalen Adressgenerator (en) zur Ansteuerung der Speicher 
nach 1 und 2 . 

2.2.6 Umgang mit Zustanden 

Es wird nun ftir die Zwecke des beschriebenen Compilers zwi- 
schen algorithmisch relevanten und irrelevanten Zustanden un- 
terschieden. Zustande werden in der VPU-Technologie ftir ge- 
wohnlich durch Statussignale (z.B. Trigger in PACT08) und/oder 
Handshakes (z.B. RDY/ACK in PACT02) dargestellt. Generell kon- 
nen Zustande (v. a. in anderen Technologien, wie FPGAs, DPGAs, 
Chameleon-Bausteinen, Morphics, etc.) durch beliebige Signale, 
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Signalbundel und/oder Register dargestellt werden. Das offen- 
barte Compilierverf ahren kann auch auf solche angelegt werden, 
obwohl wesentliche Telle der Beschreibung bevorzugt auf die 
VPU fokussleren. 

Relevante Zustande sind innerhalb des Algorithmus notwendig urn 
dessen korrekte Funktion zu beschreiben. Sie sind fiir den Al- 
gorithmus wesentllch. 

Irrelevante ZustSnde entstehen durch die verwendete Hardware 
und/oder die gewahlte Abbildung oder aus anderen sekundaren 
Griinden. Sie sind damit ftir die Abbildung (also die Hardware) 
wesentlich. 

Lediglich die relevanten Zustande mtissen mit den Daten erhal- 
ten werden. Daher werden diese zusammen mit den Daten in den 
Speichern abgelegt, da sie entweder als Ergebnis der Verarbei- 
tung mit den Daten auftraten oder als Operanden mit den Daten 
fur den nSchsten Verarbeitungszyklus notwendig sind. 

Irrelevante Zustande sind dagegen nur ortlich und/oder zeit- 
lich lokal notwendig und mtissen daher nicht gespeichert wer- 
den. 

Beispiel: 

a) Die Zustandsinformation eines Vergleichs ist far die weite- 
re Verarbeitung der Daten relevant, da dieser die auszuftlh- 
renden Funktionen bestimmt. 

b) Angenoramen, ein sequentieller Dividierer entsteht bei- 
spielsweise durch Abbildung eines Divisionsbefehles auf ei- 
ne Hardware, die nur die sequentielle Division unterstatzt. 
Dadurch entsteht ein Zustand, der den Rechenschritt inner- 
halb der Division kennzeichnet . Dieser Zustand ist irrele- 
vant, da fur den Algorithmus nur das Ergebnis (also die 
ausgefuhrte Division) erforderlich ist. In diesera Fall wer- 
den also lediglich das Ergebnis und die Zeitinformation 
(also die Verfiigbarkeit) benStigt. Der Compiler unterschei- 
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det solche relevante und irrelevante Zustande bevorzugt 
voneinander . 

Die Zeitinformation ist beispj/elsweise in der VPU-Technologie 
nach PACTOl, 02, 13 durch das RDY/ACK Handshake erhaltlich. 
Hierzu ist jedoch besonders' anzumerken, dass das Handshake 
ebenfalls keine relevanten Zustand darstellt, da es lediglich 
die Gaitigkeit der Daten signalisiert, wodurch sich wiederum 
die verbleibende relevante Information auf die Existenz giilti- 
ger Daten reduziert. 



2.2.7 Umgang mit Zeit 

In vielen Programmiersprachen, besonders in sequentiellen wie 
z.B. C, wird eine exakte zeitliche Reihenfolge iraplizit durch 
die Sprache vorgegeben; bei sequentiellen Programmiersprachen 
geschieht dies beispielsweise durch die Reihenfolge der ein- 
zelnen Anweisungen. Sofern dies durch die Programmier sprache 
und/oder den Algorithmus erforderlich ist, wird das Compilier- 
verfahren so ausgefiihrt, dass sich die Zeitinformation auf 
Synchronisationsmodelle wie RDY/ACK und/oder REQ/ACK oder ein 
Time-Stamp-Verfahren nach DE 101 10 530.4 abbilden lasst. 

Mit anderen Worten wird die implizite Zeitinfoinnation von se- 
quentiellen Sprachen in ein Handshake Protokoll derart abge- 
bildet, dass das Handshake Protokoll (RDY/ACK-Protokoll) die 
Zeitinfoimiation ubertrSgt und insbesondere die Reihenfolge der 
Zuweisungen garantiert . 

Beispielsweise wird die nachfolgende for-Schleife nur dann 
durchlaufen und iteriert, wenn die Variable input stream je 
Durchlauf mit einem RDY quittiert ist. Bleibt RDY aus, wird 
der Schleif endurchlauf bis zum Eintreffen von RDY angehalten. 
while TRUE 
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s := 0 

for i:= 1 to 3 

s := s + inputstream; 

Die Eigenschaft der sequentiellen Sprachen, nur von der Be- 
fehlsverarbeitung gesteuert zu warden, wird somit bei der Com- 
pilierung mit dem Datenf luBprinzip, die Verarbeitung durch den 
Datenstrom, bzw. die Existenz von Daten zu steuern verbunden. 
Mit anderen Worten wird ein Befehl und/oder eine Anweisung 
(z.B. s := s + inputstream;) nur verarbeitet, wenn die Opera- 
tion ausgefuhrt werden kann und die Daten verfiigbar sind. 

Bemerkenswert ist, dafi dieses Verfahren gewohnlicherweise zu 
keiner Anderung der Syntax oder Semantik einer Hochsprache 
fiihrt. Es kann also vorhandener Hochsprachencode durch Neucom- 
pilierung problemfrei zur Ausfuhrung auf einer VPU gebracht 
werden . 



2.2.8 Laden und Speichern von Daten 

Far die Grundlagen der Load/Store Operationen ist folgendes 
beachtlich. 

Die nachfolgenden Adressierungsarten werden unterschiedlich 
behandelt : 

1. externe Adressierung, also die Datentransfers mit exter- 
nen Baugruppen 

2 . interne Adressierung, also die Datentransfers zwischen 
PAEs, i.b. zwischen RAM-PAEs und ALU-PAEs 

Desweiteren kann die zeitliche Entkopplung der Datenverarbei- 
tung und dem Laden und Speichern der Daten besondere Beachtung 
finden. 
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Bustransfers werden in interne und externa Transfers zerlegt. 
btl) Externe Lesezugriffe (Load Operation) werden separiert, 
in einer itiQglichen Ausfiihrung auch bevorzugt in eine separate 
Konfiguration ubersetzt. Die Uaten werden von einem externen 
Speicher in einen internen transferiert . 

bt2) Interne Zugriffe werden mit der Datenverarbeitung gekop- 
pelt, d.h. die internen Speicher (Register Operation) werden 
fiir die Datenverarbeitung gelesen, bzw. beschrieben. 

bt3) Externe Schreibzugrif f e (Store Operation) werden sepa- 
riert, in einer bevorzugten mSglichen Ausfiihrung auch in eine 
separate Konfiguration abersetzt. Die Daten werden von einem 
internen Speicher in einen externen transferiert. 

Wesentlich ist, dass die btl, bt2, bt3 - also das Laden der 
Daten (Load) , das Verarbeiten der Daten (Datenverarbeitung und 
bt2) und das Schreiben der Daten (bt3) - in unterscheidliche 
Konfigurationen tibersetzt werden kSnnen und diese ggf . zu ei- 
nem unterschiedlichen Zeitpunkt ausgeftihrt werden. 

Das Verfahren soil an dem nachf olgenden Beispiel verdeutlicht 
werden : 

function example (a, b : integer) -> x : integer 
for i:= 1 to 100 
for j:= 1 to ICQ 

x[i] := a[i] * b[j] 

Die Funktion kann vom Compiler in drei Telle, bzw. Konfigura- 
tionen (subconfig) transf ormiert : 

example#dload: LSdt die Daten von extern (Speicher, Periphe- 
rie, etc.) und schreibt diese in interne Speicher. Interne 
Speicher sind mit r# und dem Namen der ursprvinglichen Variable 
gekennzeichnet . 
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example#process : Entspricht der eigentlichen Datenverarbei- 
tung. Diese liest die Daten aus internem Operanden und 
schreibt die Ergebnisse wieder in interne Speicher. 
example#dstore: schreibt die ETrgebnisse aus dem internen Spei- 
cher nach extern (Speicher, Peripherie, etc.). 

function example* (a, b : integer) -> x : integer 
subconfig exaraple#dload 
for i := 1 to 100 

r#a[i] := a[i] 
for j := 1 to 100 

r#b[jl := b[j] 

subconfig example#process 
for i := 1 to 100 
for j:= 1 to 100 

r#x[i] := r#a[i] * r#b[j] 

subconfig exampletdstore 
for i := 1 to 100 
x[i] := r#x[i] 

Ein wesentlicher Effekt des Verfahrens ist, dass anstatt i*j = 
100 * 100 = 10.000 externe Zugriffe nur i+j = 100 + 100 = 200 
externe Zugriffe zum Lesen der Operanden ausgeftihrt werden. 
Diese Zugriffe sind zudem noch vollkommen linear, was die 
Trans fergeschwindigkeit bei modernen Bussystemen (Burst) 
und/oder Speichern (SDRAM, DDRAM, RAMBUS, etc) erheblich be- 
schleunigt . 



Die internen Speicherzugrif f e erfolgen parallel, da den Ope- 
randen unterschiedliche Speicher zugewiesen wurden. 
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Zum Schreiben der Ergebnisse sind i = 100 externe Zugriffe 
notwendig, die ebenfalls wieder linear mit maximaler Perfor- 
mance erfolgen konnen. 

Wenn die Anzahl der Datentransf ers vorab nicht bekannt ist 
(z.B. WHILE-Schleif en) oder sehr groli ist, kann ein Verfahren 
verwendet werden, das bei Bedarf durch Unterprogrammauf ruf e 
die Operanden nachladt bzw. die Ergebnisse nach extern 
schreibt. Dazu konnen in einer bevorzugten Ausfuhrung (auch) 
die Zustande der FIFOs abgefragt werden: 'empty' wenn das FIFO 
leer ist, sowie 'full' wenn das FIFO voll ist. Entsprechend 
der Zustande reagiert der Prograiranf lufi - Zu bemerken ist, dass 
bestimmte Variablen (z.B. ai, bi, xi) global definiert sind. 
Zu Perf ormanceoptimierung kann ein Scheduler entsprechend der 
bereits beschriebenen Verfahren die Konf igurationen examp- 
le#dloada, example #dloadb bereits vor dem Aufruf von examp- 
le#process bereits ausfiihren, sodass bereits Daten vorgeladen 
sind. Ebenso kann example#dstore (n) nach der Terminierung von 
example#process noch aufgerufen werden um r#x zu leeren. 

subconfig exainple#dloada (n) 
while !full(r#a) AND ai<=n 
r#a[ai] := a[ai] 
ai++ 

subconfig example#dloadb (n) 
while !full{r#b) AND bi<=n 
r#b[bi] := b.[bi] 
bi++ 

subconfig example#dstore (n) 
while ! empty (r#x) AND xi<=n 
x[xi] := r#x[xi] 
xi++ 
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subconfig exainple#process 
for i := 1 to n 
for j := 1 to m 

if empty (r#a) then exampleTttdloada (n) 

if empty (r#b) then example#dloadb (m) 

if full(r#x) then example#dstore (n) 



r#x[i] := r#a[i] * r#b[j3 
bj := 1 

Die Unterprogrammaufrufe und das Vefwalten der globalen Varia- 
blen sind fur rekonf igurierbare Architekturen vergleichsweise 
aufwendig. Daher kann in einer bevorzugten Ausftihrung die 
nachfolgende Optimierung durchgefuhrt werden, in welcher samt- 
liche Konfigurationen weitgehend unabangig ablaufen und nach 
vollstandiger Abarbeitung terminieren (terminate) . Da die Da- 
ten b[j] mehrfach erforderlich sind, mufi example#dloadb ent- 
sprechend mehrfach durchlaufen werden. Dazu werden beispiels- 
weise zwei Alternativen dargestellt: 

Alternative 1: example#dloadb terminiert nach jedem Durchlauf 
und wird von example#process fur jeden Neustart neu konfigu- 
riert . 

Alternative 2: example#dloadb lauft unendlich und wird von ex- 
ample#process terminiert. 



wahrend 'idle' ist eine Konf iguration untatig (wartend) . 



subconfig example#dloada (n) 
for i:= 1 to n 
while full(r#a) 

idle 
r#a[i] := a[i] 
terminate 



subconfig example#dloadb (n) 
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while 1 // ALTERNATIVE 2 
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for i:= 1 to n 
while full(r#b) 

idle 
r#b[i] :== a[i] 
tejrminate 

subconfig example#dstore (n) 
for i:= 1 to n 
while empty (r#b) 

idle 
x[i] := r#x[il 
terminate 

subconfig exampletprocess 
for i := 1 to n 
for j := 1 to m 

while empty (r#a) or empty (r#b) or full(r#x) 
idle 

r#x[i] := r#a[i] * r#b[j] 
conficj examiDle^dloadb (n) // ALTERNATIVE 1 
terminate exampleidloadb (n) // ALTERNATIVE 2 
terminate 

Zur Vermeidung von Wartezyklen konnen Konf igurationen auch 
terminiert werden, sobald sie ihre Aufgabe temporSr nicht wel- 
ter erf alien konnen. Die entsprechende Konf igurat ion wird von 
dem rekonf igurierbaren Baustein entfernt, verbleibt jedoch im 
Scheduler. Hierzu wird im Folgenden der Befehl 'reenter' ver- 
wendet. Die relevanten Variablen werden vor der Terminierung 
gesichert und bei der wiederholten Konf iguration wiederherge- 
stellt: 



subconfig example#dloada (n) 
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if full(r#a) reenter 

r#a[ai] := a[ai] 
tearminate 

subconf ig exampleidloadb (n) 
while 1 // ALTERNATIVE 2 
for bi:= 1 to n 

if full(r#b) reenter 
r#b[bi] := a[bi] 
terminate 

subconf ig example#dstore (n) 
for xi:= 1 to n 

if empty (r#b) reenter 

x[xi] := r#x[xi] 
terminate 

subconfig example#process 
for i := 1 to n 
for j := 1 to m 

if empty (r#a) or empty (r#b) or full(r#x) reenter 
r#x[i] := r#a[i] * r#b[j] 
confiQ example#dloadb (n) // ALTERNATIVE 1 
terminate exampleidloadb (n) // ALTERNATIVE 2 
terminate 

2.3 Makros 

Komplexere Funktionen einer Hochsprache, wie z.B. Schleifen, 
werden typisch durch Makros realisiert. Die bdakros werden da- 
bei vom Compiler vorgegeben und zur Obersetzungszeit instanti- 
iert . (vgl . Figur 4 ) . 



PCT/EP02/1006S 
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Die Makros sind entweder aus einfachen Sprachkonstrukten der 
Hochsprache oder auf Assemblerlevel auf gebaut . Makros konnen 
parametrisiert sein, um eine einfache Adaption an den beschie- 
benen Algorithmus zu erm5glicl)ten. (vgl. Figur 5, 0502) . Die 
Makros sind auch vorliegend einzugliedern. 

2 . 4 Feedback Loops und Register 

Innerhalb der Abbildung eines Algorithmus in ein kombinatori- 
sches Netz konnen unverzogerte Ruckkopplungen entstehen, die 
unkontrolliert schwingen. 

In praktisch implementierten VPU-Technologien gemaB PACT02 
wird dies durch einen Aufbau der PAE verhindert, bei welchem 
mindestens ein Register zur Entkopplung, etwa fest in den 
PAEs, definiert ist. 

Generell sind unverzogerte Ruckkopplungen durch Graphenanalyse 
des entstandenen koinbinatorischen Netzes f eststellbar . In die 
Datenpfade, in denen eine unverzogerte RUckkopplung besteht, 
werden daraufhin gezielt Register zur Entkopplung eingefugt. 
Der Compiler kann somit Register- beziehungsweise Speichermit- 
tel verwalten. 

Durch die Verwendung von Handshake-Protokollen (z.B. RDY/ACK 
gem. 2.2.7) ist die korrekte Funktion der Berechnung auch 
durch das EinfUgen von Registern sichergestellt . 

2.5 Prozssormodell / Time Domain Multiplexing (TDM) 
Grundsatzlich besitzt jede praktisch realisierte PAE-Matrix 
lediglich eine endliche Grofie. Daher rauJi im folgenden Schritt 
eine Partitionierung des Algorithmus nach 2.2.5 Abs . 4 a/b in 
eine Mehrzahl von Konf igurationen durchgefiihrt werden, die 
nacheinander in die PAE-Matrix konfiguriert werden. Ziel ist 
typisch, moglichst viele Datenpakete in dem Netzwerk zu be- 
rechnen, ohne umkonf igurieren zu raussen. 
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Zwischen den Konf igurationen wird eine Zwischenspeicherung 
vorgenommen, wobei der Zwischenspeicher - ahnlich eines Regi- 
sters bei CPUs - die Daten zwi'Schen den einzelnen sequentiell 
ausgefiihrten Konf igurationen speichert. 

Somit wird durch das Rekonf igurieren von Konf igurationen, der 
Datenverarbeitung in der PAE-Matrix und der Zwischenspeiche- 
rung in den Speichern ein sequentielles Prozessormodell aufge- 
baut . 

Mit anderen Worten wird in der VPU-Technologie durch die be- 
schriebene Compilierung nicht ein OpCode sequentiell ausge- 
fuhrt, sondern komplexe Konf igurationen. wahrend bei CPUs ein 
Opcode typischerweise ein Datenwort bearbeitet, werden in der 
VPU-Technologie eine Mehrzahl von Datenworten (ein Datenpaket) 
von einer Konf iguration bearbeitet. Dadurch steigt die Effizi- 
enz der rekonf igurierbar en Architektur durch ein besseres Ver- 
haltnis zwischen Rekonf igurationsaufwand und Datenverarbei- 
tung . 

In der VPU-Technologie wird zugleich anstatt eines Registers 
ein Speicher verwendet, da nicht Datenworte, sondern Datenpa- 
kete zwischen den Konf igurationen bearbeitet werden. 

Dieser Speicher kann als Random-Access Memory, Stack, FIFO 
Oder als beliebige andere Speicherarchitektur ausgestaltet 
sein, wobei typischerweise mit einem FIFO die beste und am 
einfachsten zu realisiernde M5glichkeit gegeben ist. 

Daten werden nunmehr durch die PAE-Matrix, entsprechend des 
konf igurierten Algorithmus, bearbeitet und in einem oder meh- 
reren Speichern gespeichert- Die PAE-Matrix wird nach der Be- 
arbeitung einer Menge von Daten umkonf iguriert und die neue 
Konf iguration entniramt die Zwischenergebnisse aus dera/den 
Speicher (n) und setzt die Ausfiihrung des Programmes fort. Da- 
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bei kSnnen durchaus auch neue Daten von externen Speichern 
und/oder der Peripherie zusatzlich in die Berechnung einflie- 
iien, ebenso konnen Ergebnisse an externen Speichern und/oder 
der Peripherie geschrieben weifden. 

Mit anderen Worten ist der typische Abiauf einer Datenverar- 
beitung das Auslesen von internen RAMs, das Verarbeiten der 
Daten in der Matrix und das Schreiben von Daten in die inter- 
nen Speicher, wobei- zur Datenverarbeitung auch beliebige ex- 
terne Quellen oder Ziele fiir Datentransf ers zusatzlich oder 
anstelle der internen Speicher verwendet werden konnen. 

wahrend "sequencen" bei CPUs als das Neuladen eines Opcodes 
definiert ist, wird nach dem Vorstehenden "sequencen" von VPUs 
also als das (Re) konf igurieren von Konf igurationen definiert. 
Dies bedeutet allerdings nicht, dafi nicht unter bestimmten Be- 
dingungen Teile des Feldes als Sequenzer im herkOmmlichen Sin- 
ne betrieben werden kOnnten. 

Die Information, wann und/oder wie gesequenzt wird, d.h. wel- 
che nachste Konf igurat ion konfiguriert werden soil, ist durch 
verschiedene Infoinnationen darstellbar, die einzeln oder kom- 
biniert verwendet werden kbnnen. Z. B- sind folgende Strategi- 
en zur Ableitung der Information allein und/oder in Kombinati- 
on bzw. alternativ sinnvoll: 

a) durch den Compiler zur Obersetzungszeit definiert; 

b) durch das Event-Net zwerk definiert 
(Trigger, DE 197 04 728.9), 

wobei das Event net zwerk interne und/oder externe ZustSnde 
reprasentieren kann; 

c) durch den Ftillgrad der Speicher 

(Trigger, DE 197 04 728.9, DE 196 54 846.2-53). 



2.5.1 EinfluB des TDM auf das Prozessormodell 
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Die Partitionierung des Algorithmus bestimmt entscheidend die 
relevanten Zustande, die in den Speichern zwischen den ver- 
schiedenen Konf igurationen abgelegt werden. Sofern ein Zustand 
nur innerhalb einer Konf iguraifion relevant ist (lokal relevan- 
ter Zustand) , ist es nicht notwendig, diesen zu speichern, was 
vom Compilierverfahren bevorzugt berucksichtigt wird. 

Zu Zwecken des Debuggings des auszufiihrenden Programmes kann 
es aber sinnvoll sein, diese Zustande dennoch zu speichern, um 
dem Debugger einen Zugriff auf diese zu ermoglichen. Auf die 
DE 101 42 904.5 wird verwiesen; diese ist hiermit vollumfang- 
lich zu Of fenbarungs zwecken eingegliedert . 

Weiterhin kannen zusatzlich Zustande relevant werden, wenn ein 
Taskswitch-Mechanismus (z.B. durch ein Betriebssystem oder In- 
terruptquellen) verwendet wird und aktuelle ausgefuhrte Konfi- 
gurationen unterbrochen werden, andere Konf igurationen geladen 
werden und/oder zu einem spateren Zeitpunkt die abgebrochene 
Konfiguration fortgesetzt werden soil. Eine detailliertere Be- 
schreibung folgt im nachf olgenden Abschnitt. 

Ein einfaches Beispiel soli ein Unterscheidungsmerkmal fiir lo- 
kal relevante Zustande aufzeigen: 

a) Eine Verzweigung des Types "if () then ... else ..." pafit 
vollstandig in eine einzige Konfiguration, d.h. beide Da- 
tenpfade (Zweige) sind gemeinsam vollstandig innerhalb der 
Konfiguration abgebildet. Der sich beim Vergleich ergebende 
Zustand ist relevant, jedoch lokal, da er in den nachf ol- 
genden Konf igurationen nicht mehr benStigt wird. 

b) Dieselbe Verzweigung ist zu grofl, um vollstandig in eine 
einzige Konfiguration zu passen. Mehrere Konf igurationen 
sind notwendig, um die vollstSndigen Datenpfade abzubilden. 
In diesem Fall ist der Zustand global relevant und muii ge- 
speichert und den jeweiligen Daten zugeordnet werden, da 
die nachfolgenden Konf igurationen bei der Weiterverarbei- 
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tung der Daten den jeweiligen Zustand des Vergleichs beno- 
tigen. 



2.6 Task-Switching 

Einen zusatzlichen EinfluJi auf die Betrachtung und den Umgang 
mit Zustanden hat der mogliche Einsatz eines Betriebssystemes . 
Betriebssysteme verwenden beispielsweise Task-Scheduler ziim 
Verwalten mehrere Aufgaben (Tasks), um ein Multitasking zur 
Verfiigung zu stellen. 

Task-Scheduler brechen Tasks zu einem bestiinmten Zeitpunkt ab/ 
starten andere Tasks und kehren nach deren Abarbeitung zur 
Weiterbearbeitung des abgebrochenen Tasks zuriick. 
Sofern sichergestellt ist, dafi eine Konf iguration - die hier 
der Abarbeitung eines Tasks entsprechen kann - nur nach der 
kompletten Abarbeitung - d.h. wenn alle innerhalb dieses Kon- 
f igurationszyklusses zu bearbeitende Daten und Zustande ge- 
speichert sind - terminiert, konnen lokal relevante Zustande 
ungespeichert bleiben. Dieses Verfahren, also das komplette 
abarbeiten einer Konf iguration und der nachfolgende Taskswitch 
ist die bevorzugte Methode fiir den Betrieb von rekonf igurier- 
baren Prozessoren und entspricht im Wesentlichen dem Ablauf in 
einem normalen Prozessor, der auch zunachst die aktuell bear- 
beiteten Instruktionen abarbeitet und dann den Task wechselt. 

Ftir manche Anwendungen ist jedoch eine besonders kurze Reakti- 
on auf eine Taskwechselsanf orderung erf orderlich, z.B. in 
Realtime-Anwendungen. Hier kann es sinnvoll sein Konfiguratio- 
nen vor deren kompletter i\barbeitung abzubrechen. 
Sofern der Task-Scheduler Konf igurationen vor deren vollstan- 
diger Abarbeitung abbricht, ititissen lokale Zustande und/oder 
Daten gespeichert werden. Weiterhin ist dies von Vorteil, wenn 
die Abarbeitungszeit einer Konf iguration nicht vorhergesagt 
werden kann. In Verbindung mit dem bekannten Halteproblem und 
dem Risiko, daB eine Konf iguration (z.B. durch einen Fehler) 
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gar nicht terminiert, erscheint dies weiterhin sinnvoll, uxa 
damit einen Deadlock des gesamten Systems zu verhindern. 
Daher sind vorliegend, unter Beriicksichtung von Taskwechseln, 
relevante Zustande auch als seiche anzusehen, die fiir einen 
Taskwechsel und ein erneutes korrektes Aufsetzen der Datenver- 
arbeitung notwendig sind. 

Bei einem Taskswitch ist somit der Speicher far Ergebnisse und 
ggf . auch der Speicher fiir die Operanden zu sichern und zu ei- 
nem spSteren Zeitpunkt, also bei der Ruckkehr zu diesem Task, 
wieder herzustellen . Dies kann vergleichbar zu den PUSH/POP 
Befehlen und Verfahren nach dem Stand der Technik erfolgen. 
Weiterhin ist der Zustand der Datenverarbeitung zu sichern, 
also der Zeiger auf die zuletzt vollstandig bearbeiteten Ope- 
randen. Es sei hier besonders auf PACT18 verwiesen. 

Abhangig von der Optimierung des Taskswitches gibt es bei- 
spielsweise zwei MQglichkeiten: 

a) Die abgebrochene Konf iguration wird neu konfiguriert und 
nur die Operanden werden geladen. Die Datenverarbeitung be- 
ginnt so von neuem, als ob die Bearbeitung der Konfigurati- 
on noch gar nicht begonnen wurde. Mit anderen Worten werden 
einfach alle Datenberechnungen von vorne an ausgefiihrt, wo- 
bei ggf. Berechnungen bereits zuvor durchgeftihrt wurden. 
Diese MOglichkeit ist einfach, aber nicht effizient. 

b) Die abgebrochene Konf iguration wird neu konfiguriert, wobei 
die Operanden und die bereits berechneten Ergebnisse in die 
jeweiligen Speicher geladen werden. Die Datenverarbeitung 
wird bei den Operanden fortgesetzt, die nicht mehr voll- 
standig berechnet wurden. Dieses Verfahren ist sehr viel 
effizienter, setzt aber voraus, dafi ggf- zusStzliche Zu- 
stande, die wahrend der Verarbeitung der Konf iguration ent- 
stehen, relevant werden, etwa wenn zumindest ein Zeiger auf 
die zuletzt vollstandig verrechneten Operanden gesichert 



wo 03/017095 PCT/EP02/10065 

28 

warden muss, damit bei deren Nachfolgern nach erfolgter 
neuer Konf iguration neu aufgesetzt werden kann. 



2 . 7 Kontext Switch 

Eine besonders bevorzugte Variante zur Verwaltung von relevan- 
ten Daten wird durch den nachfolgend beschriebenen Kontext 
Switch zur Verfiigung gestellt. Bei Task-Wechseln und/oder bei 
der Ausftihrung von Konf igurationen und derem Wechsel (siehe 
beispielsweise Patentanmeldung DE 102 05 653.1, die zu Offen- 
barungszwecken volliamf anglich eingegliedert ist) kann es er- 
forderlich sein, Daten Oder ZustSnde, die typischerweise nicht 
zusaininen mit den Arbeitsdaten in die Speicher abgelegt werden, 
da sie beispielsweise lediglich einen Endwert markieren, fiir 
eine nachfolgende " Konf iguration zusichern. 

Der erf indungsgemaB bevorzugt impleraentierte Kontext Switch 
wird derart durchgef Uhrt, dass eine erste Konf iguration ent- 
fernt wird und die zu sichernden Daten in entsprechenden Spei- 
chern (REG) (Speicher, Register, Zahler, etc) verbleiben. 

Dann kann eine zweite Konf iguration geladen werden, diese ver- 
bindet die REG in geeigneter Weise und definierter Reihenfolge 
mit einem oder mehreren globalen Speicher (n). 
Die Konf iguration kann beispielsweise Adressgeneratoren ver- 
wenden, xm auf den/die globalen Speicher zuzugreifen. Es ist 
also nicht erforderlich, vorab jeden einzelnen Speicherplatz 
durch den Compiler festlegen zu lassen und/oder auf als Spei- 
cher ausgestaltete REG zuzugreifen. 

Entsprechend der konf igurierten Verbindung zwischen den REG 
werden die Inhalte der REG in einer definierten Reihenfolge in 
den globalen Speicher geschrieben, wobei die jeweiligen Adres- 
sen von Adressgeneratoren vorgegeben werden. Der Adressgenera- 
tor generiert die Adressen fur den/die globalen Speicher (n) 
derart, dass die beschriebenen Speicherbereiche (PUSHAREA) der 
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entfernten ersten Konf iguration eindeutig zugeordnet warden 
konnen . 

Es werden somit bevorzugt fur unterschiedliche Konf igurationen 
unterschiedliche Adressenraum^ verges ehen. Die Konf iguration 
entspricht dabei einem PUSH gewohnlicher Prozessoren. 

Danach verwenden andere Konf igurationen die Ressourcen. 

Nun soli die erste Konf iguration wieder gestartet werden. Zu- 
vor wird eine dritte Konf iguration gestartet, die die REG der 
ersten Konf iguration in einer definierten Reihenfolge mitein- 
ander verbindet. 

Die Konf iguration kann wiederum beispielsweise Adressgenerato- 
ren verwenden um auf den oder die globalen Speichern zuzugrei- 
fen und/oder um auf als Speicher ausgestaltete REG zuzugrei- 
fen. 

Ein Adressgenerator generiert dabei Adressen bevorzugt derart, 
dass ein korrekter Zugriff auf die der ersten Konf iguration 
zugeordnete PUSHAREA erfolgt. Die generierten Adressen und die 
konf igurierte Reihenfolge der REG sind derart, dass die Daten 
der REG in der ursprtinglichen Ordnung aus den Speichern in die 
REG geschrieben werden. Die Konf iguration entspricht einem POP 
gewohnlicher Prozessoren. 

Nun wird die erste Konf iguration wieder gestartet. 

Zusammengef aBt wird ein Kontext Switch bevorzugt derart durch- 
gefiihrt, dass durch das Laden besonderer Konf igurationen, die 
ahnlich von PUSH/POP bekannter Prozessorarchitekturen arbei- 
ten, die zu sichernden Daten mit einem. globalen Speicher aus- 
getauscht werden. Dieser Datenaustausch Ober globale Speicher 
mittels von Push/Pop-Austauschkonf iguationen wird als beson- 
ders relevant angesehen. 
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Die Funktion soil in einem Beispiel verdeutlicht werden: 

Eine Funktion addiert 2 Zahlenreihen, die LSnge der Reihen ist 

zur Obersetzungszeit nicht bel^'annt, sondern erst zur Laufzeit. 

proc example 

while Klength do 
x[i] = a[i] + b[i] 
i = i + 1 

Die Funktion wird nun wahrend ihrer Ausfuhrung unterbrochen, 
beispielsweise durch einen Task-Switch, oder well der fiir x 
vorgesehene Speicher voll ist. a,b,x befinden sich zu diesem 
Zeitpunkt erf indungsgemalS in Speichern. i und ggf . length miis- 
sen jedoch gesichert werden. 

Dazu wird die Konf iguration example terminiert, wobei die Re- 
gisterinhalte erhalten bleiben und eine Konf iguration push ge- 
startet, die i und length aus den Registern liest und in einen 
Speicher schreibt. 

proc push 

memt<push_adr_example>] = i 
push_adr_example++ 
mem[<push_adr_example>] = length 

Nach der Ausfuhrung wird push terminiert und die Registerin- 
halte konnen gelOscht werden. 

Andere Konf igurationen werden ausgefilhrt. Nach einiger Zeit 
wird die Konf iguration example wieder gestartet. 
Zuvor wird eine Konf iguration pop gestartet, die die Registe- 
rinhalte wieder aus dem Speicher liest. 

proc pop 

i = mem[<push_adr_example>] 
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push_adr_example++ 

length = mem[<push_adr_example>] 

Nach der Ausfiihrung wird pop 1?rerminiert und die Registerinhal- 
te bleiben bestehen. Die Konf iguration example wird wieder ge- 
startet . 

2.8 Algorithmische Optimierunq 

Durch das beschriebene Obersetzungsverfahren werden Kontroll- 
strukturen von algorithmischen Strukturen getrennt. Beispiels- 
weise zerfallt eine Schleife in einen Rumpf (WHILE) und eine 
algorithmische Struktur (Anweisungen) . 

Die algorithmischen Strukturen lassen sich nunmehr bevorzugt 
optional durch ein zusStzliches, der Trennung nachgeschaltetes 
Werkzeug optimieren. 

Beispielsweise kann eine nachgeschaltetes Algebra-Software die 
programmierten Algorithmen optimieren und minimieren. Derarti- 
ge Tools sind z.B. unter Bezeichnungen wie AXIOM, MARBLE, etc. 
bekannt. Durch die Minimierung kann eine schnellere AusfUhrung 
des Algorithmusses und/oder ein erheblich verringerter Platz- 
bedarf erreicht werden. 

Das Ergebnis der Optimierung wird danach wieder in den Compi- 
ler geftlhrt und entsprechend weiterverarbeitet . 
Es soil zudem angemerkt sein, dass moderne Compiler {- 
Frontends) bereits eine Anzahl von Optimierungen fur Algo- 
rithemen (auch z.T. algebraische) implementiert haben, die 
selbstverstandlich im Rahmen des hier beschriebenen Verfahrens 
weiterhin nutzbar sind. 

Es soli ausdriicklich erwahnt sein, dass die beschriebenen Ver- 
fahren, insbesondere jedoch die Abschnitte 2.2.7 "Umgang mit 
Zeit" und 2.3 "Makros" auch auf Compiler nach PACT20 angewen- 
det werden k5nnen. PACT20 wird diesbeztiglich zu Of f enbarungs- 
zwecken vollumf anglich in diese Patentanmeldung einbezogen. 
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3. Anwendbarkeit ftir Prozessoren nach dem Stand der Technik^ 
xnsbesondere mlt VLIW-Architek-bTar 

Es soli besonders angemerkt warden, daB anstatt einer PAE- 
Matrix auch eine Anordnung von arithmetisch logischen Einhei- 
ten nach dem Stand der Technik (ALUs), wie beispielsweise in 
VLIW-Prozessoren tiblich, und/oder eine Anordnung von komplet- 
ten Prozessoren, wie beispielsweise in Multiprozessorsystenien 
ublich, verwendet warden kann. Ein Sonderfall stellt dabei die 
Verwendung einer einzelnen ALU das, sodali das Verfahren auch 
fur normale CPUs verwendbar ist. 

In der Dissertation [Referenz Dissertation Armin Nuckel] wurde 
ein Verfahren entwickelt, das die Ubersetzung der WHILE- 
Sprache in semantisch korrekte endliche Automaten erm5glicht. 
Daruber hinaus kann ein endlicher Automat als "Unterprograitim" 
verwendet warden und umgekehrt. Dadurch entsteht die Moglich- 
keit, eine Konf iguration auf unterschiedliche Implement ie- 
rungstechnologien abzubilden, wie z.B. CPUs; symmetrische Mul- 
tiprozessoren; FPGAs; ASICs; VPUs. 

Insbesondere ist es moglich, Teilen einer Applikation die je- 
weils optimal geeignete Hardware zuzuordnen bzw. eine jeweilie 
Eignung zu bestiramen und anhand der mahr oder weniger guten 
Eignung die optimale Hardware zuzuordnen. Dabei sind bevorzugt 
auch temporSre Ressourcenverteilungen und -reservierungen er- 
faJibar. Mit anderen Worten wiirde beispielsweise eine Daten- 
fluBstruktur einer Datenf luJiarchitektur zugeordnet werden, 
wahrend eine sequentielle Struktur auf einen Sequenzer abge- 
bildet wird, sofern diese vorhanden und/oder verfugbar sind. 

Die entstehende Problemstellungen der Ressourcenzuweisungen 
fiir die einzelnen Algorithmen kOnnen z.B. durch einen "Job As- 
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signmenf-Algorithmus zur Verwaltung der Zuordnung gelost wer- 
den. 



4 . implementierting 

Die Implement ie rung eines erf indungsgemaJSen Compilers soil von 
eine "normalen" sequentiellen Programmiersprache ausgehen, al- 
so z.B. C Oder Pascal. Diese Sprachen weisen die Eigenschaft 
auf , dass durch ihren sequentiellen Charakter eine zeitliche 
Abfolge implizit und kiinstlich durch die Sprachendef inition an 
sich generiert wird. 
Beispiel A: 



Zeile 1 
Zeile 2 
Zeile 3 
Zeile 4 



i++ 
a = i 
X = p 
j = i 



Durch die Sprachdef inition ist fest vorgegeben, dass Zeile 1 
vor Zeile 2 vor Zeile 3 vor Zeile 4 ausgefuhrt wird. Aller- 
dings kGnnte Zeile 4 auch direkt nach Zeile 1 ausgefilhrt wer- 
den und somit parallel zu Zeile 2 und 3 bearbeitet werden. 

Mit anderen Worten werden durch sequentielle Sprachen weitere 
kiinstliche und nicht algorithmisch bedingte Zustande einge- 
baut. Wichtig ist lediglich die korrekte zeitliche Abfolge der 
Berechungen in Beispiel A. Zeile 4 darf erst berechnet werden, 
wenn i korrekt definiert ist, also nach der Abarbeitung von 
Zeile 1. Auch Zeile 2 darf erst nach der korrekten Definition 
von i (also nach der Abarbeitung von Zeile 1) verarbeitet wer- 
den. Zeile 3 benotigt die Ergebnisse von Zeile 2 (die Variable 
a) und darf daher erst nach derer korrekten Definition berech- 
net werden. Somit ergibt sich eine Datenabhangigkeit aber kei- 
ne besonderen Zustande. 



Anhand der Datenabhangigkeiten der Variable a in Zeile 2 und 3 
(Zeile 3 verwendet a als Operand, a ist das Ergebnis von Zeile 
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2) kann automatisch durch den Compiler folgende Transformation 
zur Reprasentation der Parallelisier- bzw. Vektorisierbarkeit 
(ParVec-Trans format ion) durchgefiihrt warden: 

Zeile 2: VEC{a = i * b; 
Zeile 3: x = p - a} 

VEC bedeutet, dass jeder durch ' ; ' getrennte Ausdruck nachein- 
ander abgearbeitet wird, wobei die Ausdriicke innerhalb der ge- 
schweiften Klammern grundsatzlich gepipelinet warden konnen. 
Bevorzugt mussen samtliche Berechnungen am Ende von VEC{} 
durchgefUhrt und abgeschlossen sein, damit die Datenverarbei- 
tung hinter VEC fortgesetzt wird. 

Besser wird in einer internen Reprasentation der Datenstruktu- 
ren im Compiler die beiden Berechnungen als ein Vektor mar- 
kiert: 

VEC{a=i*b; x=p-q} 

Zeile 4 ergibt einen einfachen Vektor: 
VEC{j = i*i} 

Da sich Zeile 4 gleichzeitig zu Zeile 2 und 3 berechnen lasst 
kann die Parallelitat f olgendermassen ausgedruckt werden: 

PAR { { VEC { a=i*b ; x=p-a } ; VEC { j =i* i } } 

PAR bedeutet, dass jeder durch '{..}' getrennte Ausdruck zeit- 
gleich abgearbeitet werden kann. Bevorzugt raiissen samtliche 
Berechnungen am Ende von PAR{ } durchgeftlhrt und abgeschlossen 
sein, damit die Datenverarbeitung hinter PAR fortgesetzt wird. 



Wird Zeile 1 mit einbezogen, ergibt sich: 
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VEC{i++; PAR{ {VEC{a=i*b; x=p-a} } { VEC{ j=i*i } } } } 

Da VEC{j=i*i} ein Vektor mit nur einem Element darstellt, kann 
auch wir folgt geschrieben werden: 

VEC{i++; PAR{{VEC{a=i*b; x=p-a} } { j=i*i} } } 

Ein weiteres Beispiel zeigt einen echten Zustand. 

Beispiel B: 

Zeile 1: i++ 

Zeile 2: a = i * b 

Zeile 3: if a < 100 { 

Zeile 4: x = p - a 

Zeile 5: } else { 

Zeile 6: j = i * i } 

Jetzt kann Zeile 6 nur noch nach der Berechnung von Zeile 2 
und Zeile 3 ausgefiihrt werden. Die Berechnung von Zeile 4 und 
6 findet alternativ statt. Also ist der Zustand von Zeile 3 
ftlr die weitere Datenverarbeitung relevant (relevanter Zu- 
stand) . 

Bedingte Zustande konnen bei einer Transformation' durch IF 
ausgedriickt werden: 



Zeile 1-2: VEC{i++; a=i*b} 



Zeile 3 
Zeile 4 
Zeile 6 



IF{ {a<100}{zeile4}{zeile6}} 

VEC{x=p-a} 

VEC{j=i*i} 



Zusammengef afit ergibt das 

VEC{i++; a=i*b; IF{ {a<100} {VEC{x=p-a} } {VEC{ j=i*i} } } } 
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Weitere relevante Zustande werden durch Schleif en erzeugt : 
Beispiel C: 



Zeile 1 
Zeile 2 
Zeile 3 



for (i = 1, i < lao, i++) 

a = a * i 
q = p / a 



Zeile 3 darf erst ausgefiihrt werden, nachdem die Schleife ter- 
miniert ist. Also bestehen bei bedingten Spriingen relevante 
Zustande. 

Eine erste Transformation der Schleife ergibt: 
Zeile 1: i=l; 

Zeile 2: loop: if i >= 100 then exit 
Zeile 3: a = a * i 

Zeile 4: i++ 
Zeile 5: jump loop 

Zeile 6: exit: q = p / a 



Zeile 3 und 4 kannen parallel berechnet werden, da Zeile 4 
nicht vom Ergebnis von Zeile 3 abhcingt:" 



PAR{{a=a*i}{i++}} 



Zeile 5 ergibt einen Vektor mit dem generierten PAR, da erst 
nach vollstandiger Berechnung der Werte wieder in die Schleife 
gesprungen werden darf (hier liegt also eine zeitliche Abhan- 
gigkeit vor) . 



VEC{PAR{ {a=a*i} {i++} }; jump loop} 
Somit ergibt sich fiir die Bedingung: 

loop: IF{{i>=100}{jiamp exit} {VEC{ PAR{ {a=a*i} {i++} } ; jump 
loop}}} 
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Die Zeile 1 ist ein Vektor mit der Bedingung, da diese vor der 
Bedingung ausgefilhrt werden muss (IF verwendet i als Operand, 
i ist das Ergebnis von Zeile 1) . 

Zeile 6 ist wiederum ein VektqTr mit der Bedingung, da a als 
Operand verwendet wird und a das Ergebnis der Bedingung ist- 

Somit ergibt sich (in ubersichtlicher Schreibweise) : 
VEC{ 

i++; 

loop: IF{ 

{i>=100} 
{jump exit} 
{VEC{ 

PAR{ 

{a=a*i} 
{i++} 

}; 

jump loop 
} 

} 

}; 

exit: q=p/a 

} 

Die Inhalte von VEC{} und PAR{ } konnen als rein k'ombinatori- 
sche Netze betrachtet werden. 

Bevorzugt wird VEC und PAR ale Petri-Netz ausgestaltet, um wie 
bevorzugt die Weiterverarbeitung nach kompletter Verarbeitung 
der jeweilgen Inhalte zu steuern. 

Durch die mogliche Betrachtung von VEC und PAR als rein kombi- 
natorisches Netz entsteht die Notwendigkeit den Schleifenzu- 
stand zu sichern. D.h. in diesem Fall ist es tatsachlich not- 
wendig einen endlichen Automaten zu schaffen. 
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Die Anweisung REG{ } speichert dazu Variablen in einem Regi- 
ster. Sorait entsteht durch die Verwendung der kombinatorischen 
Netze VEC und PAC in Verbindung mit dem Register REG ein end- 
licher Automat, der exakt entsprechend des Algorithmus aufge- 
baut ist: 

VEC{ 

i++; 

loop: IF{ 

{i>=100} 
{jump exit} 
{VEC{ 

PAR{ 

{a=a*i} 
{i++} 

}; 

REG{a;i} 
jump loop 
} 

} 

}; 

exit: q=p/a 

} 

Es soli besonders darauf hingewiesen werden, dass in der VPU 
Technologie des Anmelders (vgl. PACT21) Ein- und/oder Aus- 
gangsregister an den PAEs vorgesehen sind und die zeitliche 
Korrektheit und die Verfugbarkeit von Daten durch ein inte- 
griertes Handshake-Protokoll (RDY/ACK) sichergestellt ist. In- 
soweit wird die Forderung bevorzugt beira Verlassen von VEC{ } 
Oder PAR{ } deren interne Datenverarbeitung abgeschlossen zu 
haben automatisch fur alle nachfolgend verwendeten Veriablen 
erfullt (ware die Datenverarbeitung nicht beendet, wurden 
nachfolgende Berechnungsschritte auf die Beendigung und das 
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Eintreffen der Daten wart en) . Durch die integrierten Register 
sind auch schwingende Riickkopplungen ausgeschlossen. 



Insoweit ist nachf olgender Teriii fur diese Technologie korrekt: 
VEC{PAR{ {a=a*i} {i++} }; jump loop} 



Fur andere Technologien, die die o.g. Ausgestaltungen nicht 
Oder nur teilweise aufweisen, sollte der Terra f olgendermassen 
formuliert werden: 

VEC{PAR{ {a=a*i}{i++}}; REG{a;i}; jump loop} 

Es soil darauf hingewiesen werden, dass diese Form auf jeden 
Fall auch in der VPU-Technologie des Anmelders zu einer kor- 
rekten und optimalen Abbildung des Algorithmus auf den rekon- 
f igurierbaren Prozessor fuhrt. 

REG kann innerhalb der kombinatorischen Netze VEC und PAR ver- 
wendet werden. Streng betrachtet verlieren dadurch VEC und PAR 
die Eigenschaft der kombinatorischen Netze. Abstrakt kann je- 
doch REG als ein komplexes Element (REG-Element ) eines kombi- 
natorischen Netzes betrachtet werden, dem eine eigene Abarbei- 
tungszeit zugrunde liegt. Die Bearbeitung der nachf olgenden 
Elemente wird vom der Beendigung der Berechnung des REG- 
Elementes abhSngig gemacht. 

In dem Bewusstsein dieser begriff lichen Ungenauigkeit wird ei- 
ne Verwendung von E^G innerhalb von VEC und PAR im Weiteren 
zugelassen und ist insbesondere auch notwendig. 

Wie bereits vorstehend erwShnt, ist die Verwendung von REG ty- 
pischerweise innerhalb einer Konf iguration einer VPU des An- 
melders nicht erforderlich, sondern explizit immer nur dann, 
wenn die Berechnungsergebnisse einer Konf iguration abgespei- 
chert werden, sodass REG ein diesem Anwendungsf all tatsachlich 
dem expliziten Register eines endlichen Automaten entspricht. 
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Neben der Synthase von endlichen Automaten fiir Schleifen, sind 
insbesondere in einem weiteren Fall endliche Automaten erfor- 
derlich: 

1st ein Algorithmus zu grofl, urn komplett innerhalb der PAEs 
eines rekonf igurierbaren Prozessors abgearbeitet zu werden, 
mufi er in mehrere Teilalgorithmen zerlegt warden. Jeder Tei- 
lalgorithmus stellt eine Konf iguration fiir den rekonfigurier- 
baren Prozessor dar. Nacheinander, also sequentiell, werden 
die Teilalgorithmen auf den Prozessor konf iguriert , wobei die 
Ergebnisse der j swells vorhergehenden Konf iguration (en) fur 
die jeweils neue Konf iguration als Operanden dienen. 

Mit anderen Worten entsteht durch die Rekonf iguration ein end- 
licher Automat, der zu einem Zeitpunkt t Daten bearbeitet und 
speichert und zu einem Zeitpunkt t+1, moglicherweise nach ei- 
ner Konf iguration, die gespeicherten Daten ggf . anders verar- 
beitet und wieder speichert. Wesentlich ist, dass t nicht im 
klassischen Sinn durch Takte Oder Befehle definiert wird, son- 
dern durch Konf igurationen. Hierzu sein besonders die Presen- 
tation Prozessormodell (PACT, Oktober 2000, San Jose) referen- 
ziert . 

Mit noch anderen Worten besteht eine Konf iguration aus einem 
kombinatorischen Netz aus VEC und/oder PAR, dessen Ergebnisse 
gespeichert werden (REG) , um in der nachsten Konf iguration 
weiterverwendet zu werden: 

Konf iguration 1: VEC { Operands ; {VEC 1 PAR} ;REG{Resultsl } } 
Konfiguration 2: VEC{Resultsl; {VEC I PAR} ;REG{Results2 } } 

Zum einfacheren Verstandnis haben die obigen Beispiels und Be- 
schreibungen die Konstrukte VEC, PAR und REG in der Hochspra- 
chen eingeftihrt und diese dadurch strukturiert . Typischerweise 
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und bevorzugt wird diese Strukturierung erst aber auf der Ebe- 
ne der Zwischensprache (siehe Principles of Compiler Design 
(Red Dragon) , Aho, Sethi, Ullmann) eingefuhrt. 

Es soli besonders darauf hingdwiesen werden, dass die Struktu- 
rierung von Algorithmen mit VEC, PAR und REG typischerweise 
vollkonmen automatisch durch den Compiler durch Methoden wie 
z.B. Graphenanalyse durchfiihrbar ist. 

Insbesondere ist es aber auch denkbar und teilweise von Vor- 
teil dem Programmierer selbst die Strukturierungsmoglichkeit 
in der Hochsprache dadurch zu ermoglichen, dass VEC, PAR und 
REG wie oben aufgezeigt direkt in der Hochsprache beschreibbar 
sind. 



Generlerang 

Die autoraatische Erstellung von VEC, PAR und REG kann auf un- 
terschiedlichen Ebenen einen Compilierungsvorganges durchge- 
ftihrt werden. Die zunSchst einleuchtendste ist wShrend eines 
Praprozessor-Durchlauf es auf Basis des Source-Codes wie in den 
vorigen Beispielen beschrieben. Fiir die weitere Compilierung 
ist danach allerdings ein speziell angepasster Compiler erfor- 
derlich. 

Ein weiterer Aspekt ist, dass Compiler zumeist automatische 
Optimierungen von Code vornehmen (z.B. in Schleifen) . Eine ef- 
fiziente Zerlegung des Codes ist daher erst nach den Optimie- 
rungslaufen sinnvoll, insbesondere wenn Compiler (wie z.B. 
SUIF, Universitat Stanford) bereits den Code fUr Parallelisi- 
serung und/oder Vectorisierung hin optimieren. 

Die daher besonders bevorzugte Methode ist die Einbindung der 
Analysen in das Backend eines Compilers. Das Backend tibersetzt 
eine compilerinterne Datenstruktur auf die Befehle eines Ziel- 
prozessors . 
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Als compilerinterne Datenstrukturen werden zumeist Zeiger- 
strukturen wie DAGs/GAGs, Trees oder 3~Adress-Codes verwendet 
(siehe Principles of Compiler . Design (Red Dragon), Aho, Sethi, 
Ullmann) . Teilweise werden auch Stack-Machine-Codes verwendet 
{siehe Compiler selbstgeschneidert, C'T 1986 1-5) . Da die Da- 
tenformate prinzipiell Equivalent sind und ineinander trans- 
formiert werden konnen, setzt die erf indungsgemafi bevorzugte 
Methode auf der Weiterverarbeitung von Graphen, wie bevorzugt 
Trees, auf. 

Datenabhangikeiten und mSgliche Parallelitaten entsprechend 
dem vorstehend beschriebenen Verfahren sind innerhalb von 
Trees einfach auf Basis der Struktur automatisch zu erkennen. 
Hierzu konnen beispielsweise bekannte und etablierte Verfahren 
der Graphenanalyse eingesetzt werden. Alternativ oder optional 
kann durch entsprechend adaptierte Parsingmethoden ein Algo- 
rithmus auf Datenabhangikeiten, Schleifen, Sprtinge etc. hin 
untersucht werden. Dabei kann ein Verfahren ahnlich dem der 
Auswertung von Ausdrucken in Compilern verwendet werden. 

Abbxldtmg 

Die weitere Transformation des Algorithmus ist nunmehr stark 
von der Zielarchitektur abhangig. Beispielsweise bietet die 
Prozessorarchitektur des Anmelders (VPU, XPP) automatische Da- 
tensynchronisation in Hardware. Das bedeutet, dass die korrek- 
te zeitliche Abfolge von Datenabhangigkeiten automatisch in 
der Hardware gehandhabt wird. Andere Architekturen benotigen 
zum Teil zusStzlich die Synthese geeigneter Zustandsmaschinen 
ftir die Steuerung es Datentransf ers . 

Besonders interessant ist die Handhabung bedingter Sprtinge. 
Beispielswiese stellt die Prozessorarchitektur des Anmelders 
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mehrere Mechanismen zu derer Abbildung und Ausfiihrung zur Ver- 
f iigung : 

1. Rekonfiguration des Prozessors oder Teilen des Prozessors 
durch eine libergeordnete Konf i'gurationseinheit (vgl. Patentan- 
meldung(en) PACTOl, 04, 05, 10, 13, 17) 

2. Auswalzen der Funktion in das Array aus PAEs (vgl. Pa- 
tentanmeldung PACT08), dabei werden z.B. beide raoglichen Zwei- 
ge eines Vergleiches zugleich auf das Array abgebildet. 

3. Wave Rekonfiguration nach Patentanmeldung (en) PACT08, 13, 
17), dabei wird den unterschiedlich zu bearbeitenden Daten ein 
Token mitgegeben, das die jeweils gultige Konf iguration wahlt. 

Es soil erwahnt sein, dass der Mechanismus 1 der allgemein ty- 
pisch anzuwendende Fall ist. Der Mechanismus 2 ist bereits bei 
den meisten Technologien sehr aufwendig oder gar nicht iinple- 
mentierbar und der Fall 3 ist bislang nur aus der VPU- 
Technologie des Anmelders bekannt. 

Die jeweils zu wahlende Ausfuhrungsmethode hSngt von der Kom- 
plexitat des Algorithmus , dem erf orderlichen Datendurchsatz 
(Performance) und der exakten Ausgestaltung des Zieiprozessors 
ab (z.B. Anzahl der PAEs) . 
Beispiele: 

Ein einfacher Vergleich soil folgendes Berechnen: 
if i < 0 then a=a*(-i) else a=a*i 

Eine Rekonfiguration des Prozessors (Mechanismus 1) je nach 
Ergebnis des Vergleichs scheint wenig sinnvoll zu sein. 
Das Auswalzen beider Zweige in das Array (Mechanismus 2) ist 
Grundsatzlich moglich. Je nach Ergebnis des Vergleichs werden 
entweder die a=a*(-i) oder a=a*i berechnenden PAEs angesteuert 
(vgl. PACT08) . 

Besonders platzef f izient ist das Uberlagern der beiden Berech- 
nungen (Mechanismus 3) , wodurch nach dem Vergleich unabhangig 
vom Ergebnis dieselbe(n) PAEs die Daten weiterverarbeiten, die 
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Daten aber mit einem Token versehen sind, das sodann in Abhan- 
gigkeit vom Vergleich lokal in den jeweils nachf olgenden die 
Daten verarbeitenden PAEs entweder die Funktion a=a*(-i) oder 
a=a*i auswahlt. (vgl. PACT08, 13, 17). 

Nach Mechanismus 1 entsteht ein global relevanter Zustand, da 
die komplette folgende Konfiguration davon abhangig ist. 

Nach Mechanismus 2 und 3 entstehen nur ein lokal relevanter 
Zustand, da dieser uber die Berechnung hinaus - die vollstan- 
dig implementiert ist - nicht mehr benotigt wird. 

Mit anderen Worten kann die lokale oder globale Relevanz von 
Zustanden auch von der gewShlten Abbildung auf die Prozessor- 
architektur abhangen. 

Ein Zustand der uber eine Konfiguration hinaus und somit iiber 
das kombinatorische Netz des eine Konfiguration reprSsentie- 
renden endlichen Automaten hinaus relevant ist (also von nach- 
folgenden endlichen Automaten benotigt wird) , kann grundsatz- 
lich als global betrachtet werden. Es soil nochmals auf die 
verwendete diffuse Terminologie des Begriffes kombinatorisches 
Netz hingewiesen werden. 

Befehlsmodell des entstandenen Prozessors 

Entsprechend der vorliegenden Erfindung entsteht ein Prozes- 
somodell ftir rekonf igurierbare Prozessoren, das alle wesent- 
lichen Befehle umfafit: 

Arithmetisch/logische Befehle werden direkt in das kombinato- 
rische Netz abgebildet. 

Sprunge (Jump/Call) werden entweder direkt in das kombinatori- 
sche Netz ausgewalzt oder durch Rekonf iguration realisiert. 
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Bedinqung und Kontrollf lufibef ehle (if^ etc) werden entweder im 
kombinatorischen Netz vollstandig aufgelSst und bearbeitet 
Oder an eine libergeordnete Konf igurationseinheit weitergelei- 
tet, die sodann entsprechend dfes entstandenen Status eine Re- 
konf iguration durchfuhrt. 

Load/Store-Operationen werden bevorzugt in separate Konf igura- 
tionen abgebildet und durch Adressgeneratoren ahnlich den be- 
kannten OMR's realisiert, die internen Speicher {REG{}) mit- 
tels Adressgeneratoren in externe Speicher schreiben oder die- 
se von externen Speichern und/oder Peripherie laden. Sie kon- 
nen aber auch zusaramen mit der datenverarbeitenden Konfigura- 
tion konfiguriert sein und arbeiten. 

Reqister-Move-Operationen werden im kombinatorischen Netz 
durch Busse zwischen den internen Speichern (REG{}) reali- 
siert . 

Push/Pop-Operationen werden durch separate Konf igurationen 
realisiert, die ggf . bestimmte interne Register im kombinato- 
rischen Netz und/oder die internen Speicher (REG{}) mittels 
Adressgeneratoren in externe Speicher schreiben oder aus ex- 
ternen Speichern lesen und die bevorzugt vor oder nach den ei- 
gentlichen datenverarbeitenden Konf igurationen ausgefuhrt wer- 
den. 

5 . Beschreibung der Figuren 

Die nachf olgenden Figuren zeigen Implementierungs- und Ausge- 
staltungsbeispiele des Compilers. 

Pigur la zeigt den Aufbau eines gewahnlichen endlichen Automa- 
ten, bei welchem ein kombinatorisches Netz (0101) mit einem 
Register (0102) verknUpft ist. Daten konnen direkt an 0101 
(0103) und 0102 (0104) gefUhrt werden. Durch eine Rtickkopplung 
(0105) des Registers auf das kombinatorische Netz ist die Ver- 
arbeitung eines Zustandes in Abhangigkeit des/der vorhergehen- 
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den Zustande moglich. Die Verarbeitungsergebnisse werden durch 
0106 dargestellt. 

Pigur lb zeigt eine Reprasent^ion des endlichen Automaten 
durch eine rekonf igurierbare Architektur nach PACTOl und 
PACT04 (PACT04 Fig. 12-15) . Das kombinatorischen Netz aus Fi- 
gur la (0101) wird durch eine Anordnung von PAEs 0107 ersetzt 
(0101b). Das Register (0102) wird durch einen Speicher (0102b) 
ausgefahrt, der mehrere Zyklen speichern kann. Die Ruckkopp- 
lung gemafi 0105 erfolgt durch 0105b. Die Eingange (0103b bzw. 
0104b) sind aquivalent 0103 bzw 0104. Der direkte Zugriff auf 
0102b kann ggf . durch einen Bus durch das Array 0101b reali- 
siert werden. Der Ausgang 0106b ist wiederum aquivalent 0106. 



Figur 2 zeigt die Abbildung eines endlichen Automaten auf eine 
rekonf igurierbare Architektur. 0201 (x) reprSsentieren das kom- 
binatorische Netz (das entsprechend Figur lb als PAEs ausge- 
staltet sein kann) . Es existieren ein oder mehrere Speicher 
fur Operanden (0202) und ein oder mehrere Speicher fur Ergeb- 
nisse (0203) . Zusatzliche Daten Ein-/Ausgange gem. 0103b, 
0104b, 0106b) sind der Einfachheit halber nicht dargestellt. 
Den Speichern zugeordnet ist jeweils ein Adressgenerator 
(0204, 0205) . 

Die Operanden- und Ergebnisspeicher (0202, 0203) sind physika- 
lisch Oder virtuell derart miteinander verkoppelt, daii bei- 
spielsweise die Ergebnisse einer Funktion bzw. einer Opera- 
tion elner anderen als Operanden dienen konnen und/oder sowohl 
Ergebnisse als auch neu zugefiihrte Operanden einer Funktion 
einer anderen als Operanden dienen kSnnen. Eine derart ige 
Kopplung kann beispielsweise durch Bussysteme hergestellt wer- 
den Oder durch eine (Re) Konf iguration durch welche die Funkti- 
on und Vernetzung der Speicher mit den 0201 neu konfiguriert 
wird. 
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Figur 3 zeigt verschiedene Aspekte zum Umgang mit Variablen. 
In Figur 3a zeigen 0301, 0302, 0303 verschiedene Stufen der 
Berechnung. Diese Stufen konnen rein kombinatorisch oder auch 
iiber Register voneinander getaj^nnt sein. fl, f.2, f3 sind Funk- 
tionen, xl ist eine Variable gemaii Patentbeschreibung. 
Figur 3b zeigt die Verwendung einer Variablen xl in der Funk- 
tion xl := xl + 1. 

Figur 3c zeigt das Verhalten eines endlichen Automaten zur Be- 
rechnung von xl := xl + 1 innerhalb einer Konf iguration. In 
der nachsten Konf iguration sind 0306 und 0304 zu vertauschen 
um einen vollstandigen endlichen Automaten zu erhalten. 0305 
reprSsentiert die Adressgeneratoren far die Speicher 0304 und 
0306. 

Figur 4 zeigt Implementierungen von Schleifen. Die schraffier- 
ten Module konnen durch Makros generiert werden (0420, 0421) . 
0421 kann auch durch Analyse des Graphen auf unverzQgerte 
Rtlckkopplungen eingefugt werden. 

Figur 4a zeigt die Implementierung einer einfachen Schleife 
der Art 
WHILE TRUE DO 

xl := xl + 1; 

Im Kern der Schleife liegt der zahler +1 (0401) . 0402 ist ein 
Multiplexer, der zu Beginn den Startwert von xl (0403) auf 
0401 fiihrt und sodann bei jeder Iteration die Ruckkopplung 
(0404a, 0404b) bewirkt . In die RUckkopplung ist ein Register 
(vgl. REG{}) (0405) eingesetzt, um eine unverzogerte und damit 
unkontrollierte Ruckkopplung des Ausgangs von 0401 auf dessen 
Eingang zu verhindern. 0405 wird mit dem Arbeitstakt der VPU 
getaktet und bestiramt damit die Anzahl der Iterationen pro 
Zeit. Der jeweilige Zahlerstand ware an 0404a oder 0404b ab- 
greifbar. Je nach Definition der Hochsprache terminiert die 
Schleife jedoch nicht. Beispielsweise ware in einer HDL (nach 
dem Stand der Technik (z.B. VHDL, Verilog) das Signal auf 0404 
nutzbar, wShrend es in einer sequentiellen Programmiersprache 
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(z.B- C) 0404 nicht nutzbar ist, da die Schleife nicht termi- 
niert und somit keinen Exit-Wert lief ert . 

Der Multiplexer 0402 realisiert ein Makro, das aus dem Schlei- 
fenkonstrukt entstanden ist. IT&s Makro wird durch die Oberset- 
zung von WHILE instantiiert . 

Das Register 0405 ist entweder ebenfalls Teil des Makros oder 
wird entsprechend einer Graphenanalyse nach dem Stand der 
Technik exakt dann und dort eingeftigt, wo eine unverz5gerte 
RUckkopplung existiert, um so die Schwingneigung auszuschal- 
ten. 

Figur 4b zeigt den Aufbau einer echten Schleife der Art 
WHILE xl < 10 DO 
xl := xl + 1; 

Der Aufbau entspricht im Kern der Figur 4a, weshalb dieselben 
Referenzen verwendet wurden. 

Zusatzlich ist eine Schaltung dargestellt, die die Giiltigkeit 
des Ergebnisses kontrolliert (0410) und das Signal von 0404a 
nur dann an die nachf olgenden Funktionen (0411) weiterleitet, 
wenn das Abbruchkriterium der Schleife erreicht ist. Das Ab- 
bruchkriterium wird durch den Vergleich xl < 10 festgestellt 
(Vergleichsstuf e 0412) . Als Ergebnis des Vergleiches wird das 
betreffende Statusflag (0413) an ein Multipliziermittel 0402 
zur Steuerung der Schleife und die Funktionen 0411 zur Kon- 
trolle der Ergebnisweiterfiihrung geleitet . Das Statusflag 0413 
kann beispielsweise durch Trigger gemali DE 197 04 728.9 imple- 
mentiert sein. Ebenfalls kann das Statusf lagmittel 0413 an ei- 
ne CT gesendet werden, die daraufhin die Terminierung der 
Schleife erkennt und eine Rekonf iguration durchfuhrt. 

Figur 5a zeigt die iterative Berechnung von 
FOR i:=l TO 10 

xl := xl * xl; 

Im wesentlichen entspricht die Grundfunktion Figur 4b, weshalb 
die Referenzen tibernoitimen wurden. Der Funktionsblock 0501 be- 
rechnet die Multiplikation. Die FOR-Schleife wird durch eine 
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weitere Schleife entsprechend Figur 4b implement iert und ist 
lediglich durch Block 0503 angedeutet. Block 0503 liefert den 
Status des Vergleiches auf das Abbruchkriterium. Der Status 
wird direkt zur Ansteuerung d^ Iteration verwendet, wodurch 
das Mittel 0412 (dargestellt durch 0502) weitgehend entfallt. 

Figur 5b zeigt das Auswalzen der Berechnung von 
FOR i:=l TO 10 

xl := xl * xl; 

Da die Anzahl der Iterationen zur Ubersetzungszeit exakt be- 
kannt ist, kann die Berechnung in eine Folge von i Multipli- 
zierern (0510) abgebildet werden. 

Figur 6 zeigt die Ausfuhrung einer WHILE-Schleif e gem. Figur 
4b uber raehrere Konf igurationen. Hier ist der Zustand der 
Schleife (0601) ein relevanter Zustand, da dieser die Funktion 
in den nachfolgenden Konf igurationen maligeblich beeinfluBt. 
Die Berechnung erstreckt sich uber 4 Konf igurationen (0602, 

0603, 0604, 0605) . Zwischen den Konf igurationen werden die Da- 
ten in Speichern (vgl. REG{}) abgelegt (0606, 0607). 0607 er- 
setzt dabei ebenfalls 0405. 

Als ein Rekonfigurationskriterium kann der Fiillstand der Spei- 
cher dienen, angedeutet uber 0606, 0607: Speicher voll/leer 
und/oder 0601, das den Abbruch der Schleife anzeigt. Mit ande- 
ren Worten werden durch den Fiillstand der Speicher Trigger ge- 
neriert (vgl. PACTOl, PACT05, PACT08, PACTIO) , die an die Kon- 
f igurationseinheit gesendet werden und eine Rekonf iguration 
auslosen. Auch der Zustand der Schleife (0 601) kann an die CT 
gesendet werden. Daraufhin kann die CT bei Erreichen des Ab- 
bruchkriteriums die nachfolgenden Algorithmen konf igurieren, 
bzw. ggf. zunachst die rest lichen Telle der Schleife (0603, 

0604, 0605) abarbeiten und danach die nachfolgenden Konfigura- 
tionen laden. 
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6 . Parallelxsierbaxkeit 

Figur 6 zeigt potentielle Grenf^en der Parallelisierbarkeit 
auf . 

Sofern die Berechnung der Operanden unabhangig von der Riick- 
kopplung 0608 ist, kann die Schleife blockweise, d.h. jeweils 
durch Fullen der Speicher 0606/0607 berechnet werden. Damit 
wird ein hoher Grad an Parallelitat erreicht. 

Sofern die Berechnung eines Operanden abhangig von dem Ergeb- 
nis der vorherigen Berechnung ist, also eine Ruckkopplung Oder 
dergleichen 0608 in die Berechnung einflielit, wird das Verfah- 
ren inef f izienter, da jeweils nur ein Operand innerhalb der 
Schleife berechnet werden kann. 

Ist der nutzbare ILP (Instruktionslevel Parallelismus) inner- 
halb der Schleife hoch und die Zeit fur die Rekonf iguration 
nieder (vgl. PACT02, PACT04, PACT13, PACT17), kann eine auf 
PAEs ausgewalzte Berechnung auf einer VPU weiterhin effizient 
sein. 

Ist dies nicht der Fall, ist es sinnvoll, die Schleife auf ei- 
ne sequentielle Architektur (vom PA separater Prozessor oder 
Implement ierung innerhalb des PA entsprechend DE 196 51 075.9- 
53, DE 196 54 846.2-53 und insbesondere DE 199 26 538.0 (Fig. 
5, 11, 16, 17, 23, 30, 31, 33)) abzubilden. 

Die Analyse der Berechnungszeiten kann entweder im Compiler 
zur Obersetzungszeit gemaii dem nachf olgenden Abschnitt erfol- 
gen und/oder empirisch zu der oder einer Laufzeit gemessen 
werden, um eine nachtragliche Optimierung herbeizuftihren, was 
zu einem lernfahigen, insbesondere selbstlernenden Compiler 
f ahrt . 
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FUr die Erfindung sind Analyse- und Parallelisierungsverfahren 
von Bedeutung. 

Verschiedene Verfahren nach deiti Stand der Technik stehen ftir 
die Analyse und Durchftihrung der Parallelisierung zur Verfii- 
gung. 

Ein bevorzugtes Verfahren soil im Folgenden beschrieben wer- 
den. 

Abzubildende Funktionen werden durch Graphen dargestellt (vgl. 
PACT13; DE 199 26 538.0), wobei eine Applikation aus beliebig 
vielen unterschiedlichen Funktionen zusainmengesetzt sein kann. 
Die Graphen werden auf die in ihnen enthaltene Parallelitat 
untersucht, wobei vorab samtliche Methoden der Optimierung zuiti 
Einsatz koinmen kQnnen. 

Beispielsweise sollen folgende Untersuchungen durchgeftihrt 
werden : 

6.0.1 ILP (Instruction Level Parallelism) 

ILP druckt aus, welche Befehle zeitgleich ausgefuhrt werden 
konnen (vgl. PAR{ } ) . Eine derartige Analyse wird auf Basis der 
Betrachtung von Abhangigkeiten von Knoten in einem Graphen 
einfach mSglich. Entsprechende Verfahren sind nach dem Stand 
der Technik und in der Mathematik per se hinreichend bekannt, 
as soil beispielsweise auf VLIW-Compiler und Synthesetools 
verwiesen werden. 

Besondere Beachtung benStigen aber z. B. gegebenenfalls ver- 
schachtelte bedingte Ausfahrungen (IF), da eine korrekte Aus- 
sage der parallel ausfiihrbaren Pfade oftmals kaum oder nicht 
zu treffen ist, da eine starke Abhangigkeit vom Werterauiti der 
einzelnen Parameter besteht, der oftmals nicht oder nur unzu- 
reichend bekannt ist. Auch kann eine exakte Analyse derart 
viel Rechenzeit in Anspruch nehmen, daJ5 sie nicht raehr sinn- 
voll durchfuhrbar ist. 
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In derartigen Fallen kann beispielsweise die Analyse durch 
Hinweise vom Programmierer vereinfacht werden und/oder es kann 
anhand entsprechender Corapilerschalter derart gearbeitet wer- 
den, dafi im Zweifelsfall entw^der von einer hohen Paralleli- 
sierbarkeit (ggf. unter Verschwendung von Ressourcen) oder von 
einer niederen Parallelisierbarkeit (ggf. unter Verschwendung 
von Performance) ausgegangen werden soli. 

Ebenfalls kann in diesen Fallen eine empirische Analyse zur 
Laufzeit durchgefuhrt werden. Nach PACTIO, PACT17 sind Verfah- 
ren bekannt, die zur Laufzeit die Erstellung von Statistiken 
aber das Programmverhalten erlauben. Derart kann z. B. zu- 
nachst von einer maximalen Parallelisierbarkeit ausgegangen 
werden. Die einzelnen Pfade geben Meldungen an eine Stati- 
stikeinheit (2. B. implementiert in einer CT oder einer ande- 
ren Stufe^vgl. PACTIO, PACT17, grundsatzlich konnen aber auch 
Einheiten nach PACT 04 verwenden werden) tiber jeden Durchlauf 
zurttck. Mittels statistischer Mafinahmen ist nunmehr auswert- 
bar, welche Pfade tatsachlich parallel durchlauf en werden. 
Weiterhin ergibt sich die Moglichkeit, anhand der Daten zur 
Laufzeit zu bewerten, welche Pfade haufig oder selten oder nie 
parallel durchlauf en werden. Diese Art der Pf adnutzungsmeldung 
ist nicht zwingend, aber vorteilhaft. 

Dement sprechend kann die Ausftihrung bei einem n^chsten Pro- 
granmiaufruf optimiert werden. Dafi dazu die Statistikinf ormati- 
on insbesondere nichtf luchtig. wie auf eine Festplatte wegge- 
schrieben werden kann, sei erwShnt. Aus PACT22, PACT24 ist be- 
kannt, dafi mehrere Konf igurationen entweder zugleich konfigu- 
riert werden konnen und danach durch Trigger (PACT08) ange- 
steuert werden oder nur eine Untermenge konfiguriert ist und 
die restlichen Konf igurationen bei Bedarf dadurch nachgeladen 
werden, dafi die entsprechenden Trigger an eine Ladeeinheit 
(CT, PACTIO) gesendet werden. 

Der im folgenden gebrauchte Wert PAR(p) gibt zur Verdeutli- 
chung an, welche Parallelitat auf Instruktionsniveau, d. h. 
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wieviel ILP bei einer bestimmten Stufe (p) innerhalb des aus 
der Funktion transf ormierten Datenf luligraphen erreichbar ist 
(Figur 7a) . 



Gleichfalls bedeutsam ist Vektorparallelitat (vgl. VEC{}). 
Vektorparallelitat ist nutzbar, wenn grofiere Datenmengen zu 
verarbeiten sind. In diesem Fall sind lineare Folgen von Ope- 
rationen vektorisierbar, d.h. alle Operationen konnen gleich- 
zeitig Datenverarbeiten, wobei typischerweise jede separate 
Operation ein separates Datenwort bearbeitet. 

Innerhalb von Schleifen ist dieses Vorgehen teilweise nicht 
mOglich. Daher sind Analysen und Optimierungen notwendig. 
Beispielsweise kann der Graph einer Funktion durch ein Petri- 
netz ausgedrilckt werden. Petri-Netze besitzen die Eigenschaft, 
dafi die Ergebnisweitergabe von PCnoten kontrolliert erfolgt, 
wodurch beispielsweise Schleifen modelliert werden kOnnen. 
Durch die Rtickkopplung des Ergebnisses in einer Schleife wird 
der Datendurchsatz bestiinmt . Beispiele: 

• Das Ergebnis der Berechnung n wird fUr die Berechnung n+1 

ben5tigt: Nur eine Berechnung kann innerhalb der Schleife 
ausgefiihrt werden. 

• Das Ergebnis der Berechnung n wird fiir die Berechnung n+m 

benotigt: m-l Berechnungen k5nnen innerhalb der Schleife 
ausgefiihrt werden. 

• Das Ergebnis bestimmt den Abbruch der Schleife, geht aber 

nicht in die Berechnung der Ergebnis se ein: Eine Ruck- 
kopplung ist nicht notwendig. Ggf. laufen zwar falsche 
(zuviel) Werte in die Schleife, jedoch kann die Ausgabe 
der Ergebnisse direkt bei Erreichen der Endbedingung am 
Schleif enende unterbrochen werden. 

Vor der Analyse von Schleifen kOnnen diese nach dem Stand der 
Technik optimiert werden. Beispielsweise kQnnen bestiirante In- 
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struktionen aus der Schleife herausgezogen werden und vor oder 
nach die Schleife gestellt werden. 

Der im Folgenden zur VerdeutlqTchung gebrauchte Wert VEC kann 
den Grad der Vektorisierbarkeit einer Funktion veranschauli- 
chen. Mit anderen Worten zeigt VEC an, wieviele Datenworte zu- 
gleich innerhalb einer Menge von Operationen bearbeitet werden 
kOnnen. VEC kann beispielsweise aus der Zahl der benStigten 
Rechenwerke ftlr eine Funktion nnodes und der zugleich innerhalb 
des Vektors berechenbaren Daten naata berechnet werden, z.B. 
durch VEC = nnodes / ndata 

1st eine Funktion beispielsweise auf 5 Rechenwerke abbildbar 
(nnodes = 5) und in jedem der Rechenwerke k5nnen zugleich Daten 
bearbeitet werden (ndata = 5) ist VEC = 1 (Figur 7b) . 
1st eine Funktion dagegen beispielsweise auf 5 Rechenwerke ab- 
bildbar (nnodes = 5) und nur in einem Rechenwerk kdnnen jeweils 
Daten bearbeitet werden, z. B. aufgrund einer Riickkopplung der 
Ergebnisse der Pipeline auf den Eingang (ndata = 5), so ist VEC 
= 1/5 (Figur 7c) . 

VEC kann fur eine gesamte Funktion und/oder ftir Teilausschnit- 
te einer Funktion berechnet werden. FUr den erf indungsgemaiien 
Compiler kSnnen beide Varianten vorteilhaft sein, wie generell 
die Bestiiranung und Auswertung von VEC vorteilhaft ist. 

Gemafi Figur 7a wird P2Ul(p) fur jede Zeile eines Graphen be- 
stimmt, wie vorteilhaft moglich. Eine Zeile eines Graphen ist 
dadurch definiert, daB sie innerhalb einer Takteinheit ausge- 
fuhrt wird. Die Anzahl der Operationen ist von der Implemen- 
tierung der jeweiligen VPU abhangig. 

Entspricht PAR(p) der Anzahl der Knoten in der Zeile p, so 
kSnnen alle Knoten parallel ausgeftihrt werden. 
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1st PAR(p) kleiner, warden bestiinmte Knoten nur alternativ 
ausgefiihrt. Die alternativen Aiisftihrungen jeweils eines Kno- 
tens warden in jeweils einer PAE zusammengef aiSt . Eine Selakti- 
onsvorrichtung ermoglicht die /Aktivierung der, dem Status der 
Datenverarbeitung entsprechenden. Alternative zur Laufzeit wie 
beispielsweise in PACT08 beschrieben. 

VEC wird ebenfalls jeder Zeile eines Graphen zugeordnet. 1st 
fiir eine Zeile VEC = 1, bedeutet dies, daB die Zeile als Pipe- 
linestufe bestehen bleibt. 1st eine Zeile kleiner 1, so warden 
alle nachf olgenden Zeilen, die ebenfalls kleiner 1 sind zusam- 
iriengefaBt, da ein Pipelining nicht moglich ist. Entsprechend 
der Reihenfolge der Operationen warden diese zu einer Sequenz 
zusammengef afit, die dann in eine PAE konfiguriert wird und zur 
Laufzeit sequentiell abgearbaitet wird. Entsprechande Verfah- 
ren sind beispielsweise aus PCT/DE 97/02949 und/oder PCT/DE 
97/02998 bekannt. 

Durch das beschriebene Verfahren lassen sich durch Gruppierun- 
gen von Sequenzern beliebig komplexe Parallelprozessormodelle 
aufbauen. Insbesondere sind Sequenzerstrukturen zur Abbildung 
von reentrantem Code generierbar. 

Die dazu jeweils notwendigen Synchronisationen konnen bei- 
spielsweise durch das in PACT18 beschriebene TimeStamp- 
Verfahren oder bevorzugt durch das in PACT08 beschriebene 
Triggerverf ahren durchgeftihrt werden. 

Werden mehrere Sequenzer oder sequentielle Telle auf ein PA 
abgebildet, ist es aus Leistungsverbrauchsgrtinden bevorzugt, 
die Leistung der einzelnen Sequenzer aufeinander abzustimmen. 
Dies kann besonders bevorzugt derart geschehen, dafi die Ar- 
beit sfrequenzen der Sequenzer aneinander angepaiit werden. Aus 
PACT25 und PACT18 sind beispielsweise Verfahren bekannt, die 
eine individuelle Taktung von einzelnen PAEs oder PAE-Gruppen 
zulassen. 
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Die Frequenz eines Sequenzers kann dabei anhand der Anzahl von 
Zyklen bestimmt werden, die er typischerweise zur Abarbeitung 
der ihm zugewiesenen Funktion /benotigt . 

Benotigt er beispielsweise 5 Taktzyklen zur Abarbeitung seiner 
Funktion wahrend das restliche System genau einen Taktzyklus 
benetigt, um zugewiesene Aufgaben abzuarbeiten, sollte seine 
Taktung 5-mal hoher sein als die Taktung des restlichen Sy- 
stems. Bei einer Vielzahl von Sequenzern sind jeweils unter- 
schiedliche Taktzyklen moglich. Es kann eine Taktvervielfa- 
chung und/oder eine Taktteilung vorgesehen werden. 

Funktionen werden entsprechend des vorgenannten Verfahrens 
partitioniert . Beim Partitionieren werden entsprechend Spei- 
cher ftir Daten und relevanten Status eingefiigt. Weitere alter- 
native und/oder weitergehende Verfahren sind aus PACT13 und 
PACT 18 bekannt. 

Manche VPUs bieten nach PACTOl, PACTIO, PACT13, PACT17, 
PACT22, PACT24 die Moglichkeit der dif f erentiellen Rekonfigu- 
ration. Diese kann angewendet werden, wenn nur verhaltnismalSig 
wenige Anderungen innerhalb der Anordnung von PAEs bei einer 
Rekonf iguration notwendig werden. Mit anderen Worten werden 
nur die VerSnderungen einer Konf iguration gegeniiber der aktu- 
ellen Konf iguration rekonf iguriert . Die Partitionierung kann 
in diesem Fall dergestalt sein, dafi die auf eine Konf iguration 
folgenden (dif f erentielle) Konf iguration nur die notwendigen 
Rekonf igurationsdaten enthalt und keine vollstandige Konfigu- 
ration darstellt. Der Compiler der vorliegenden Erfindung ist 
bevorzugt dazu ausgebildet, dies zu erkennen und zu unterstiit- 
zen. 

Das Scheduling der Rekonf iguration kann durch den Status er- 
folgen, der Funktion (en) an eine Ladeeinheit (CT) meldet, wel- 
che ihrerseits auf Basis des eingehenden Status die nachste 
Konf iguration oder Teilkonf iguration auswahlt und konfigu- 
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riert. Im Detail sind derartige Verfahren aus PACTOl, PACT05, 
PACT 10, PACT13, PACT 17 bekannt. 

Weiterhin kann das Scheduling die Moglichkeit des Vorladens 
von Konfigurationen wahrend de'r Laufzeit einer anderen Konfi- 
guration unterstiitzen . Dabei konnen mehrere Konfigurationen 
moglicherweise auch spekulativ vorgeladen werden, d.h. ohne 
dafi sichergestellt ist, dafi die Konfigurationen tiberhaupt be- 
notigt werden. Dies ist besonders dann bevorzugt, wenn die CT 
etwa bei langeren, konf igurationsf rei abarbeitbaren Datenstro- 
men zuitiindest weitgehend unbelastet ist und insbesondere nicht 
Oder nur wenig auf gabenbelastet ist. Durch Selektionsmechanis- 
men wie etwa nach DE 197 04 728.9 werden dann zur Laufzeit die 
zu verwendenden Konfigurationen ausgewahlt (siehe auch Bei- 
spiel NLS in PACT22/24) . 

Ebenfalls konnen die lokalen Sequenzer durch den Status ihrer 
Datenverarbeitung gesteuert werden, wie etwa aus DE 196 51 
075.9-53, DE 196 54 846.2-53, DE 199 26 538.0 bekannt. Zur 
Durchftihrung ihrer Rekonf iguration kann ein weiterer abhangi- 
ger oder unabhangiger Status an die CT gemeldet werden (siehe 
beispielsweise PACT04, LLBACK) . 

Das Vorstehende wird nun mit Bezug auf weitere Figuren be- 
schrieben. Dabei werden im folgenden folgende Zeichen zur Ver- 
einfachung der Schreibung verwendet: v oder, a und. 

Figur 8a zeigt die Abbildung des Graphens nach Fig. 7a auf ei- 

ne Gruppe von PAEs bei maximaler erreichbarer Parallelitat . 
Samtliche Operationen (Instruktion il-il2) sind in einzelne 
PAEs abgebildet. 

Pigux 8b zeigt denselben Graphen, beispielsweise mit maximaler 
nutzbarer Vektorisierbarkeit . Jedoch sind die Mengen von Ope- 
rationen V2={il, 13}, V3={i4, 15, 16, 17, 18}, V4={i9, 110, 
ill} nicht parallel par (par ( { 2, 3, 4 } ) = 1. Damit lassen sich 
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Ressourcen einsparen, indem jeweils eine Menge P2, P3, P4 von 
Operationen einer PAE zugeordnet wird. Ein Statussignal zu je- 
dem Datenwort in jeder Stufe wahlt die auszuf uhrende Operation 
in der jeweiligen PAE aus. DieT PAEs sind als Pipeline (Vektor) 
vernetzt und jede PAE fuhrt je Takt eine Operation tiber je- 
weils unterschiedliche Datenwort aus . 

Es ergibt sich folgender Ablauf : 

PAEl berechnet Daten und gibt diese an PAE2 welter. Zusairmien 
mit den Daten gibt sie ein Statussignal welter, das anzeigt, 
ob 11 Oder 12 ausgefiihrt werden soli. 

PAE2 berechnet die Daten von PAEl welter. Entsprechend des 
eingehenden Statussignals wird die auszuf uhrende Operation 
(il, 12) ausgewahlt und berechnet. Entsprechend der Berechnung 
gibt PAE2 ein Statussignal an PAE3 weiter, das anzeigt, ob (14 

V 15) V (16 V 17 V 18) ausgefuhrt werden soil. 

PAE3 berechnet die Daten von PAE2 welter. Entsprechend des 
eingehenden Statussignals wird die auszuf uhrende Operation (14 

V 15) V (16 V 17 V 18) ausgewahlt und berechnet. Entsprechend 
der Berechnung gibt P2VE3 ein Statussignal an PAE4 welter, das 
anzeigt ob 19 v 110 v ill ausgefuhrt werden soil. 

PAE4 berechnet die Daten von PAES welter. Entsprechend des 
eingehenden Statussignals wird die aus zuf Uhrende Operation 19 

V 110 V ill ausgewahlt und berechnet. 
PAES berechnet die Daten von PAE4 welter. 

Ein mogliches entsprechendes Verfahren und Hardware, die eine 
besonders giinstige Umsetzung des beschriebenen erlaubt, ist in 
DE 197 04 728.9 (Figuren 5 und 6) beschrieben; auch PACT04 und 
PACTIO, PACT13 beschreiben allgemein nutzbare, jedoch aufwen- 
digere Verfahren. 

Pigur 8c zelgt wiederiam denselben Graphen. In diesem Beisplel 
ist eine Vektorisierung nicht mOgllch, jedoch 1st PAR(p) hoch. 
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was bedeutet, dafi innerhalb einer Zeile jeweils eine Vielzahl 
von Operationen gleichzeitig ausgefuhrt werden kann. Die 
parallel durchf ahrbaren Operationen sind P2 = {il a i2}, P3 = 
{14 A 15 A 16 A 17 A 18}, P4 =i {19 A 110 a 111}. Die PAEs slnd 
derart vernetzt, dafi sle belleblge Daten belleblg unterelnan- 
der austauschen kOnnen. Die elnzelnen PAEs fuhren nur dann 
Operationen durch, wenn Im entsprechenden Zyklus ein ILP be- 
steht, ansonsten verhalten sle slch neutral (NOP) , wobel ggf . 
Heruntertaktung und/oder elne Takt- und/oder Stromabschaltung 
zur Minimlerung der Verlustleistung erfolgen kann. 
Es 1st dabei folgender Ablauf vorgesehen: 

Im ersten Zyklus arbeltet nur PAE2 und glbt die Daten an PAE2 
und PAE3 welter. 

Im zweiten Zyklus arbelten PAE2 und PAES parallel und geben 
ihre Daten an PAEl, PAE2, PAE3, PAE4, PAES welter. 
Im dritten Zyklus arbelten PAEl, PAE2, PAE3;. PAE4, PAES und 
geben die Daten an PAE2, PAE3, PAES welter. 

Im vierten Zyklus arbelten PAE2/ PAE3, PAES und geben die Da- 
ten an PAE2 welter. 

Im fiinften Zyklus arbeltet nur PAE2. 

Die Funktlon benStlgt somit S Zyklen zur Berechnung. Der ent- 
sprechende Sequenzer sollte also mlt dem 5-fachen Takt im Ver- 
haitnls zu seiner Umgebung arbelten, urn elne entsprechende 
Performance zu erzielen. 

Ein mSgliches entsprechendes Verfahren 1st In PACT02 {Flguren 
19, 20 und 21) beschrleben; auch PACT04 und PACTIO, 13 be- 
schrelben allgemeln nutzbare, jedoch aufwendlgere Verfahren. 
Weitere Verfahren und/oder Hardware slnd verwendbar. 

Figur 8d. zeigt den Graphen nach Fig. 7a far den Fall, daS kel- 
nerlel nutzbare Parallelltat besteht. Zur Berechnung elnes Da- 
tenwortes mufi jede Stufe nachelnander durchlaufen werden. In- 
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nerhalb der Stufen wird immer nur genau einer der Zweige ver- 
arbeitet . 

Die Funktion benotigt ebenfalls 5 Zyklen zur Berechnung, cyl = 
(il), cy2 = (12 V 13), cy3 = (i4 v 15 v 16 v 17 v 18), cy4 = 
(19 V 110 V 111) , cy5 = (112) . Der entsprechende Sequenzer 
sollte also mlt dem 5-fachen Takt Im Verhaltnls zu seiner Uiti- 
gebung arbelten, iim elne entsprechende Performance zu erzle- 
len. 

Elne derartlge Funktion 1st belsplelswelse ahnllch Fig. 8c 
durch elnen elnfachen Sequenzer nach PACT02 ( Flguren 19, 20 
und 21)abblldbar. Auch PACT04 und PACTIO, 13 beschrelben all- 
gemeln nutzbare, jedoch aufwendlgere Verfahren. 



Die In Figur 8 dargestellten Abblldungen slnd belleblg mlsch- 
bar und grupplerbar. 

In Figur 9a 1st belsplelswelse dleselbe Funktion dargestellt, 
bel welcher die Pfade (12 a (14 v 15) a 19) und (13 a (16 v 17 
V 18) A (19 V 110)) parallel ausfuhrbar slnd. (14 v 15), 16 v 
17 V 18), (19 V 110) slnd jewells alternatlv. Die Funktion 1st 
welterhln vektorlslerbar . Damlt last slch elne Pipeline auf- 
bauen. In welcher fur 3 PAEs (PAE4, PAE5, PAE7) jewells anhand 
von Status slgnalen die jewelllg auszufuhrende Funktion be- 
stlirant ist . 

Figur 9b zelgt eln ahnllches Belsplel, bel dem elne Vektorl- 
slerung nlcht mSgllch 1st. Allerdlngs slnd die Pfade 
(11 A 12 A (14 V 15) A 19 A 112) und (13 a (16 v 17 v 18) a 
(110 V 111)) parallel- , Damlt lalit slch die optlmale Perfor- 
mance durch den Elnsatz von zwel PAEs erzlelen, die bel die 
parallelen Pfade auch parallel abarbelten. Die Synchronisation 
der PAEs unterelnander erfolgt durch Statusslgnale, die vor- 
zugswelse von PAEl generlert werden, da dlese den Beglnn (11) 
und das Ende (112) der Funktion berechnet . 
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Es soli besonders darauf hingewiesen warden, dai3 sich aus ei- 
ner mehrfachen Anordnung von Sequenzern ein symetrisch paral- 
leles Prozessormodell (SMP) odfer ahnliche, heute verwendete 
Mehrprozessormodelle ergeben konnen. 

Weiterhin soil darauf hingewiesen werden, dali samtliche Konfi- 
gurationsregister far das Scheduling auch im Hintergrund 
und/oder wahrend der Datenverarbeitung mit neuen Konf iguratio- 
nen geladen warden kSnnen. 

Es ist dies etwa moglich, wenn die Hardware wie nach DE 196 51 
075.9-53 bekannt aufgebaut ist- Es stehen dann unabhangige 
Speicherbereiche oder Register zur Verfiigung, die unabhangig 
angesprochen werden konnen. Auf bestimmte Stellen wird durch 
eingehende Trigger gesprungen, ebenfalls kann mittels Sprung- 
befehlen (JMP, CALL/RET) , die ggf. auch bedingt durchfuhrbar 
sind gesprungen werden. 

Gemaii DE 196 54 846.2-53 stehen unabhangige Schreib- und Lese- 
zeiger zur Verfugung, wodurch grundsatzlich eine Unabhangig- 
keit und sorait die MSglichkeit des Zugriffes im Hintergrund 
gegeben ist. Insbesondere ist es m5glich, die Speicher zu seg- 
mentieren, wodurch eine zusatzliche Unabhangigkeit gegeben 
ist. Mittels Sprungbef ehlen (xJMP, CALL/RET) , die ggf. auch be- 
dingt durchfuhrbar sind, kann gesprungen werden. 

Nach DE 197 04 728.9 sind die einzelnen Register, die durch 
die Trigger gewahlt werden konnen, grundsatzlich unabhangig 
und erlauben daher eine unabhangige Konf iguration, insbesonde- 
re im Hintergrund. Sprunge innerhalb der Register sind nicht 
mSglich, die Auswahl erfolgt ausschlieiilich uber die Trigger- 
vektoren. 
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Ein wesentlicher Faktor zur Bewertung der Effizienz von PAR 
und VEC ist die Art der Daten die durch die jeweilige Struktur 
verarbeitet werden. Beispielsweise ist es lohnen eine Struktur 
auszuwalzen, also zu pipelinerf und oder parallelisieren, die 
eine groJie Menge von Daten verarbeitet; wie es z.B. bei Video- 
daten oder Telekomdaten der Fall ist. Strukturen die wenige 
Daten verarbeiten (z.B. Tastatureingabe, Maus, etc.) lohnen 
sich nicht ausgewalzt zu werden, im Gegenteil sie warden nur 
anderen Algorithmen die Ressourcen blockieren. 

Somit wird vorgeschlagen anhand unterschiedlicher Hinweise nur 
die Algorithmen, Strukturen oder Telle von Algorithmen zu par- 
allelisiern und vektorisieren, die entsprechend grofie Daten- 
mengen Verarbeiten. 

Derartige Hinweise konnen beispielsweise sein: 

1. Der Datentyp (Arrays, Streams sollten z.B. aufgrund der ho- 
hen Datenmenge eher ausgewalzt werden als z.B. einzelne Zei- 
chen) . 

2. Die Art des Zugriffes (lineare Programmabf olgen sollten 
z.B. in Sequenzer abgebildet werden, wahrend Schleifen sich 
z.B. aufgrund der hohen Anzahl von Durchlaufen zum Auswalzen 
lohnen. 

3. Die Art der Quelle und/oder des Ziels (Tastatur und Maus 
haben z.B. eine zu geringe Datenrate um effizient ausgewalzt 
zu werden, dagegen ist z.B. die Datenrate bei Netzwerk 
und/oder Video Quellen oder Zielen deutlich hoher) . 

Far die Analyse k5nnen dabei eine beliebige Menge dieser Hin- 
weise hinzugezogen werden. 



7 . Beqrxf f sdef ini-bion 
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Zustand, der nur innerhalb ei- 
ner bestimmten Konf iguration 
relevant ist; 



global relevanter Zustand 



Zustand, der in mehreren Kon- 
figurationen relevant ist und 
zwischen den Konf igurationen 
ausgetauscht werden mufi; 



relevan-ber Zustand 



Zustand^ der innerhalb eines 
Algorithmus zu dessen korrek- 
ter Ausfuhrung dessen benotigt 
wird und somit durch den Algo- 
rithmus beschrieben ist und 
da von verwendet wird; 



±r relevanter Zustand 



Zustand, der fiir den eigentli- 
chen Algorithmus ohne Bedeu- 
tung ist und auch nicht im Al- 
gorithmus beschrieben ist, der 
jedoch von der ausfuhrenden 
Hardware iraplementierungsab- 
hangig ben5tigt wird 
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1. Verfahren zum Obersetzen ^fon Hochsprachen auf rekonfigu- 
rierbare Architekturen, dadurch gekennzeichnet, dafi ein 
endlicher Automat zur Berechnung derart aufgebaut wird, dafi 
ein komplexes kombinatorisches Netz aus einzelnen Funktio- 
nen gebildet wird und dem Netz Speicher zur Speicherung der 
Operanden und Ergebnissen zugeordnet sind. 

2. Verfahren zum Datenbe- und/oder verarbeitung mit einem mul- 
tidimensionalen Feld mit rekonf igurierbaren ALUs, dadurch 
gekennzeichnet, dafi ein Hochsprachencode vorgesehen und 
derart iibersetzt wird, dali ein endlicher Automat zur Be- 
rechnung aufgebaut wird, wobei ein komplexes kombinatori- 
sches Netz aus einzelnen Funktionen gebildet und dem Netz 
Speicher zur Speicherung der Operanden und/oder Ergebnisse 
zugeordnet werden. 

3. Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, daB das komplexe kombinatorische Netz so 
aufgebaut und/oder zerlegt wird, daB die PAE-Matrix mog- 
lichst lange ohne Rekonf igurat ion betrieben wird. 

4. Verfahren nach dem vorhergehenden Anspruch, dadurch gekenn- 
zeichnet, daii komplexe Instruktionen bestimmt werden, um 
das komplexe kombinatorische Netz so aufzubauen und/oder zu 
zerlegen, daB die PAE-Matrix moglichst lange ohne Rekonf i- 
guration betrieben wird. 

5. Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, daB ein endlicher Automat direkt aus impe- 
rativem Quelltext aufgebaut wird. 
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6. Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, daB ein endlicher Automat aus an grobgranu- 
lare Logikkreise und/oder an vorhandene f eingranulare Ele- 
mente (FPGA-Zellen in der A^PU, statemachines etc.) angepali- 
te Operationen aufgebaut wird, insbesondere ausschlielilich 
an soiche. 

7. Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, daB ein endlicher Automat dann in Konfigu- 
rationen zerlegt wird. 

8 . Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, daB generierte Konf igurationen succesive 
auf die PAE-Matrix abgebildet werden und Arbeitsdaten 
und/oder Zustande, die zwischen den Konf igurationen zu 
ubertragen sind, in Speicher abgelegt werden. 

9. Verfahren nach dem vorhergehenden Anspruch, dadurch gekenn- 
zeichnet, dali der Speicher vom Compiler bestimmt bezie- 
hungsweise vorgesehen wird. 

10. Verfahren nach dem vorhergehenden Anspruch, dadurch gekenn- 
zeichnet, dafi wahrend einer Konf igurat ion Daten aus einer 
VPU externen Quelle und/oder einem internen Speicher verar- 
beitet und an eine externe Quelle und/oder einen internen 
Speicher geschrieben werden. 

11. Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, daB ein Speicher fiir einen gesamten Daten- 
satz vorgesehen wird, der umf angreicher als ein einzelnes 
Datenwort ist . 

12. Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, daB bei Verarbeitung einer ablaufenden Kon- 
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figuration Daten compilerbestiinint in die Speicher abgelegt 
werden . 

13. Verfahren nach einem der \rbrhergehenden Ansprtiche, dadurch 
gekennzeichnet, dafi ein Speicher fur Operanden, ein Spei- 
cher fiir Ergebnisse und ein Netzwerk aus Zuweisungen 
und/oder Vergleichen-Anweisungen, also Bedingungen wie z.B. 
IF, CASE, Schleifen (WHILE, FOR, REPEAT) sowie optionalen 
Adressgenerator (en) zur Ansteuerung der Speicher mit dem 
Automaten vorgesehen werden. 

14. Verfahren nach eineiti der vorhergehenden Anspriiche, dadurch 
gekennzeichnet, daB Zustanden wie erforderlich Speicher zu- 
geordnet werden, und hierbei zwischen algorithmisch rele- 
vanten und irrelevanten Zustanden unterschieden wird, ins- 
besondere solchen relevanten Zustanden, die innerhalb des 
Algorithmus notwendig um dessen korrekte Funktion zu be- 
schreiben und solchen irrelevante Zustande, die durch die 
verwendete Hardware und/oder die gewahlte Abbildung oder 
aus anderen sekundSren Grunden entstehen. 



15. Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, daB Load/Store Operationen unter Vorsehen 
einer externen Adressierung, also des Datentransfers mit 
externen Baugruppen und einer interne Adressierung, also 
die Datentransfers zwischen PAEs, i.b. zwischen RAM-PAEs 
und ALU-PAEs vorgesehen werden. 

16. Verfahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, daB bei der Datenverarbeitung eine erste 
Konfiguration entfernt wird und die zu sichernden Daten in 
entsprechenden Speichern (REG) (Speicher, Register, zahler, 
etc) verbleiben. 
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17 . Verf ahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, dali die erste Konf iguration wieder geladen 
wird und auf die zuvor gesicherterten, ihr zugeordnete Da- 
ten zugreift. 



18 . Verf ahren nach einem der vorhergehenden Anspruche, dadurch 
gekennzeichnet, daB fiir den Zugriff auf zuvor gesicherterte 
Daten eine zweite Konf iguration geladen wird, die die REG 
in geeigneter Weise und definierter Reihenfolge mit einem 
Oder mehreren globalen Speicher(n) verbindet, insbesondere, 
urn unter Verwendung von Adressgeneratoren auf den/die glo- 
balen Speicher zuzugreifen, wobei der Adressgenerator die 
Adressen fur den/die globalen Speicher (n) bevorzugt derart 
generiert, dass die beschriebenen Speicherbereiche (PUSHA- 
REA) der entfernten ersten Konf iguration eindeutig zugeord- 
net werden k5nnen. 



19. Verf ahren nach einem der vorhergehenden Ansprtiche, dadurch 
gekennzeichnet, daS> automat isch Transformation zur Repra- 
sentation der Parallelisier- bzw. Vektorisierbarkeit (Par- 
Vec-Transformation) durchgefuhrt werden und/oder VEC und 
PAR-Anteile als Petri-Netz ausgestaltet werden, um wie be- 
vorzugt die Weiterverarbeitung nach kompletter Verarbeitung 
der jeweiligen Inhalte zu steuern. 



20. Verf ahren nach einem der vorhergehenden Ansprtiche, dadurch 
gekennzeichnet, da& 

arithmetisch/logische Befehle direkt in das kombinatorische 
Netz abgebildet werden und/oder 

Sprunge (Jump/Call) entweder direkt in das kombinatorische 
Netz ausgewalzt und/oder durch Rekonf iguration realisiert 
werden und/oder 

Bedingungen und Kontrollf lufibef ehle (if, etc) entweder im 
kombinatorischen Netz vollstandig aufgelost und /oder bear- 
beitet werden und/oder an eine Qbergeordnete Konfigurati- 
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onseinheit weitergeleitet werden, die sodann entsprechend 
des entstandenen Status eine Rekonf iguration durchfiihrt 
und/oder 

Load/Store-Operationen in /Separate Konf igurationen abgebil- 
det und/oder durch Adressgeneratoren realisiert werden, die 
internen Speicher (REG{}) mittels Adressgeneratoren in ex- 
terne Speicher schreiben und/oder diese von externen Spei- 
chern und/oder Peripherie laden und/oder 

Register-Move-Operationen im kombinatorischen Netz durch 
Busse zwischen den internen Speichern (REG{}) realisiert 
werden und/oder 

Push/Pop-Operationen durch separate Konf igurationen reali- 
siert werden, die bestiirante interne Register im kombinato- 
rischen Netz und/oder die internen Speicher (REG{}) mittels 
Adressgeneratoren in externe Speicher schreiben oder aus 
externen Speichern lesen und die bevorzugt vor oder nach 
den eigentlichen datenverarbeitenden Konf igurationen ausge- 
fuhrt werden. 
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